Repository navigation
The record tells the truth about releases: the v1.0.0 notes are in the repository, the v1.1.0 notes are drafted, and README says what a release is, what --version prints and what a workstation with pipx's link sees (#228, PR 4 of 4) - #269
Merged
Merged
Conversation
Phases 1-2 of /opsx:propose for #228: the change scaffold and proposal.md. Annotated vX.Y.Z tags and release/vX.Y branches after opensoft/openRepoShape#850; the openrepotools wheel carrying the whole payload for an offline --install, with --install skipping pipx's link; a dispatch-only release.yml adapted from openRepoShape's (#563); a TestPyPI rehearsal now and v1.1.0 from openRepoTools-code after the cutover (#186). Alignment review and council follow. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… answers of 2026-10-17 (#228) Applies the /opsx:propose alignment review (stack architect and QA lead) to proposal.md, each fix checked against the code first, and records Brett Heap's four answers of 2026-10-17T21:51:50Z (#228 comment 6241784787) as a dated addendum under the decisions. - the pipx skip: the exact detection rule (link, resolved target, pipx_metadata.json main_package.package), the exact skip and count lines, 28 receipt rows against 29, and the upgrade, uninstall, pip --user and pipx-home cases; the record's "as #563 did" corrected (#563 refuses) - the stamp gains the source repository; how it reaches --version (five environment variables, bash keeps the one parser) and the exact lines - the digest code is the pinned upstream/openRepoShape/scripts/repo_shape.py with submodules: true; the in-wheel layout and why the offline install holds (payload_select :969-984, assembly_above, wip_shape_ref :3242) - a new standard-library hygiene test; wheel modes checked; which bash runs - the rc upload departs from openRepoShape on Brett's word; no pypi.org publisher for this repository, on his word; the unsourced "Decision 1 accepts that risk" dropped - #852's patch-tag wording, #850's "or a merge of main" and the lanes' side - the openRepoShape pin bump to v1.1.0 before the regenerated plan (#186 comment 6241785035); the code leg's LICENSE from T006's code-0001 - Impact: AGENTS.md's CI paragraph and tests.yml's header comment - the model cited as openRepoShape v1.1.0 (190133d), published by run 39071178232; the decisions header no longer says "20:5xZ" Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ifications.md (#228) Phase 5 of /opsx:propose for #228. The council verdicts of lane openRepoTools-3 (2026-10-17T22:4xZ) go into proposal.md, VALID 1-9, surgically and with the structure kept. NOTED N1-N5 and the three dismissals go into a new clarifications.md. proposal.md: - VALID 1: a new "Coexistence with the other installers" section. It covers the move from the one-line install (pipx install --force), a checkout's --install meeting pipx's link and its count line, and the workBenches condition, stated in one bullet as position (c), pending Brett Heap's word - VALID 2: the three README passages feature 006 corrects (:240, :251-262, :302); the pipx route's text, fixed now; README gains it only once PyPI serves 1.1.0 and the workBenches condition holds; lane 3 owns that PR - VALID 3: a non-goal: --version names the command's release, not the placed files' - VALID 4: a "Release owner" section. Brett decides every tag, cut and upload, and lane 3 carries them out, step 6 included. Per the lead's correction after #186 comment 6242560541 (D3, D4): code-0001 is the code leg's first commit right after execute, LICENSE is checked as blob 261eeb9 before the first package run, and Brett's code-side environments, tag ruleset and both publishers come after execute and before v1.1.0 - VALID 5: the pipx skip as path and existence checks with a bash-3.2 readlink loop, no jq and no JSON, in every mode, before any link refusal; pipx versions corrected (model locks 1.11.1 / 1.17.8, newest 1.18.3) - VALID 6: the model's all-or-nothing stamp rule (standard.py:153-156); bash reads _release.py beside its payload with a fixed grammar; the five OPENREPOTOOLS_PACKAGE_* variables dropped; the entry module execs bash - VALID 7: the cutover invariants (the gate's four job ids in the code leg's tests.yml, no release step reading across legs, no readme in pyproject.toml), and #228's PRs land before lane 1's rehearsal and plan (D1) - VALID 8: the package job fails on skipped package tests; pipx-skip tests use fake venvs; the build asserts TREE_DIGEST_DEFINITION - VALID 9: --install refuses pip's console script in every mode, and a package-mode --install reports a shadowing openRepoTools on PATH clarifications.md: N1 detection, N2 the stamp grammar, N3 the release notes, N4 hatchling's modes (checked: 1.27.0 normalises to 0644/0755 when reproducible, the default), N5 the refusal and report wording. Also D1-D3, each with the reason it was dismissed. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… build's check, not by hatchling (#228) The lead's correction to the council verdicts' VALID 4 (after #186 comment 6242560541, D3) gives the reason for code-0001's order as "license-files = ["LICENSE"] fails without it". Hatchling 1.27.0 does not fail: its published wheel builds the licence list from a glob of each license-files pattern and raises nothing when a pattern matches no file (hatchling/metadata/core.py:757-770; add_licenses, wheel.py:714-719, only writes what matched). A code leg without LICENSE would build a wheel without one. So the proposal now adopts openRepoShape's own check (release.yml:649-655 at v1.1.0): the wheel's .dist-info holds exactly METADATA, WHEEL, RECORD, entry_points.txt and licenses/LICENSE, and that LICENSE is the commit's. The release build and the package job make it. The order (code-0001 first, right after execute), lane 3's blob check before the first package run, and "never tolerate a missing LICENSE" stand as the lead directed. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…lities (#228) Phase 6 of /opsx:propose, the first artifact: one ADDED delta per capability the proposal lists, written against the proposal as the council verdicts left it, and clarifications.md. - release-tags-and-branches: annotated vX.Y.Z tags and their message form, release/vX.Y cut at vX.Y.0, back-ports through main (fast-forward or cherry-pick -x), patch tags waiting for the commit's tests.yml runs, the release/v* push trigger, release notes and GitHub Releases after PyPI serves the version, Brett Heap's word for every act with lane 3 carrying them out, and tags staying where they were made at the cutover - pypi-package: the metadata (no dependencies, one script, no readme, the wheel's .dist-info with licenses/LICENSE), the exec'd entry point, the byte-for-byte payload, the offline install, the all-or-nothing stamp read from the package only, the exact --version lines, the pipx skip and every other link refused, upgrade and uninstall, coexistence (pip refused, the PATH report, the checkout count line), README offering only a published package, the package job, the release gates, the reproducible build, trusted-publishing uploads, the install check, rehearsals, and the cutover invariants openspec validate release-tags-pypi --strict: valid. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Phase 6 of /opsx:propose, the second artifact: how the change is built, written from the proposal, the two delta specs and clarifications.md, so that it answers N1-N5 and reopens none of D1-D3. - the package under src/ (the case-insensitive clash with the root's bash file), and a written-out force-include map that a test holds to bash's payload_names; no build hook - the entry module only execs bash, refusing with exit 2 when there is no bash, and reads no stamp: bash is the one reader - package mode decided from $SELF's path; a broken stamp refuses every invocation in package mode - N2: the stamp's fixed grammar, its refusals, writer-reader agreement, and no docstring line that hatch's case-insensitive VERSION pattern could take first (hatchling/version/core.py:6, :31 in 1.27.0); stricter than the model in three named places - N1: pipx's link resolved with a 40-hop readlink loop and cd -P / pwd -P, quoted for macOS's "Application Support" home (pipx/paths.py:14); the jq check stays where it is (R-A9-12's order); a venv-shaped link that fails the rule is refused without rm advice; fixtures for three pipx releases across four homes - the checkout count line, and the foreign stamp read beside pipx's payload - N5: how pip's console script is recognised, and the exact refusal and PATH-report text - the package job (submodules, pip wheel twice, the dist-info and LICENSE check, pipx 1.11.1 on 3.9, a JUnit count that fails on any skip, tomli pinned for 3.9) and the release.yml differences from the model - N3: the notes stay in spec, no release step reads them, and the release owner creates the Release by hand; N4: the installer owns modes - risks, including the LICENSE that hatchling would not miss and .gitattributes on git archive; migration, rollback and open questions Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ff record (#228) Phase 6 of /opsx:propose, the last artifact. As propose.md requires, it is a governance and handoff record only, with no implementation steps. It tracks: - the proposal, the review and the artifacts (done); - Brett Heap's pending word on the workBenches position; - the single Speckit feature, landing (before lane 1's rehearsal, #186 comment 6242560541 D1), and the rehearsals on his word; - the cutover's dependencies (lane 1's plan entries and invariants; code-0001 first after execute, and lane 3's LICENSE blob check); - v1.1.0 after execute, and archive readiness. Speckit Handoff: feature 006-release-pypi, branch 006-release-pypi, tasks specs/006-release-pypi/tasks.md, pending /speckit.specify. That directory is not created here. openspec validate release-tags-pypi --strict: valid. openspec status: 4/4 artifacts complete. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…gs of 2026-10-17 (#228) design.md's Open Questions gains a "Resolved by the lead" list, each item marked "Resolved by the lead, 2026-10-17": 1. the .dist-info check (exactly METADATA, WHEEL, RECORD, entry_points.txt and licenses/LICENSE, equal to the commit's) in both the release build and the package job is confirmed, as the way a missing LICENSE is made fatal; code-0001 stays the code leg's first commit after execute 2. workBenches main is noted at bdab3e2, where both of its checks still hold 3. the stricter stamp rules are confirmed: unstamped is VERSION 0.0.0 with an empty REPOSITORY, TAG is v$VERSION, REPOSITORY is a slug, and a broken stamp refuses every package-mode invocation, --help included, naming the stamp file and the fix, pipx reinstall openrepotools. Decision 4's refusal line now names that fix in place of pipx install --force openrepotools 4. the jq check staying put, the venv-looking link refused with no rm advice, the stamp reader's docstring guard and the pipx home with a space are confirmed 5. the checkout's count line is confirmed as the proposal and spec fix it Still open: Brett Heap's choice of (a), (b) or (c) on workBenches; the proposal's one dependent bullet stays pending his word. openspec validate release-tags-pypi --strict: valid. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…228) /speckit.specify for the OpenSpec change release-tags-pypi, its one linked feature, on the existing branch (the before_specify branch hook skipped). Written only from proposal.md, the two delta specs, design.md (with the lead's rulings of 2026-10-17) and clarifications.md: - six prioritised stories: install offline beside pipx (P1), know which release runs (P1), move between installers without being misled (P2), every commit proves it packages (P2), publish only through gates (P2), and the record tells the truth (P3) - FR-001..FR-046 cover all 25 delta-spec requirements (17 pypi-package, 8 release-tags-and-branches); the exact --version, skip and count lines are restated, and the pip refusal and PATH note are design.md Decision 8's - FR-047, the workBenches condition, is the one open item: pending Brett Heap's choice of (a), (b) or (c), not a blocker - edge cases, key entities, ten measurable success criteria, assumptions (Brett Heap's acts outside the repository, the cutover, lane 1's plan, the model at 190133d) and the proposal's non-goals checklists/requirements.md: every item passes in one iteration; no [NEEDS CLARIFICATION] marker remains. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ff (#228) The "Speckit Handoff" section no longer says "pending /speckit.specify". It names feature 006-release-pypi, branch 006-release-pypi, tasks specs/006-release-pypi/tasks.md, specified on 2026-10-17 by /speckit.specify (spec.md at eb12177). No checklist item is ticked here. openspec validate release-tags-pypi --strict: valid. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ts and quickstart (#228) /speckit.plan (before_plan and after_plan commit hooks skipped; no SPECKIT markers in CLAUDE.md or AGENTS.md, so no agent-context edit): - plan.md: technical context for a bash installer, a stdlib entry module, declarative hatchling 1.27.0 and two GitHub Actions workflows; twelve gates from AGENTS.md, the Build Tiers rule and the change (the constitution is the unfilled template), all passing before Phase 0 and after Phase 1; the source tree; fixed fixture-builder and test-name prefixes so that tasks agree; governed files; four pull requests - research.md R1-R18: openrepotools.cli:main; the written-out force-include map; the bash function names; the count line's source and version; pip's rule as design.md writes it (distlib's /bin/sh launcher a recorded gap); the PATH report's prefix; OPENREPOTOOLS_TEST_WHEEL for the built-wheel tests with the package job's JUnit count; workflow YAML read by the pinned repo_shape.load_yaml; the stamp writer a heredoc the suite runs; the model's hash locks re-headed; tomli by hash in the package job; the v1.0.0 notes checked by their task; dated cap entries - data-model.md, quickstart.md, and contracts/ for the CLI's exact lines, the stamp, pipx's link and pip's script and the PATH report, the wheel, and both workflows design.md Decision 8: <prefix> is five levels above payload/, the parent of its lib/, not four; the layout it writes out has five components (research R7, R17). openspec validate release-tags-pypi --strict: valid. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…d tier (#228) /speckit.tasks (before_tasks and after_tasks commit hooks skipped). Every task line carries exactly one tier tag, a files: list and a verify: command; no [H], because AGENTS.md has no "## Governed invariants" section. 19 [O] (governed files, the stamp, the release workflow and trusted publishing, contracts, the shared fixture interface, the installer's cross-cutting changes) and 6 [S]. - Phase 1-2: the stamp and __init__, pyproject.toml, and the shared fixture builders tests/package_layout.py - US1-US3 (pull request 1): tests first, then cli.py and the installer's pipx rule, stamp reader, --version, coexistence, pip refusal and PATH report - US4 (pull request 2): the model's two hash locks, tests_workflow tests, tests.yml's release/v* push and package job, AGENTS.md's CI paragraph - US5 (pull request 3): release workflow tests, then release.yml's build job, its upload and install jobs, and its RELEASING header - US6 (pull request 4): the v1.0.0 notes byte for byte, the v1.1.0 draft, README's version paragraph and three corrections - Polish: quickstart.md end to end - a "before Phase 1" note: merge origin/main (2732d59) into the branch first; a table of requirements met by acts the change's tasks.md tracks; FR-047 pending Brett Heap's word Checked: a script finds 25 well-formed task lines with no [P] overlap and every verify passing bash -n; T001's, T002's and T014's verify commands pass on a correct sample and fail on a wrong one. research.md R16 also records that main has moved (AGENTS.md 321/323 at 2732d59). Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… CRITICAL or HIGH left (#228) /speckit.analyze (before_analyze and after_analyze hooks skipped), three passes. Pass 1: 0 CRITICAL, 3 HIGH, 6 MEDIUM, 12 LOW. Pass 2: 1 more HIGH. Pass 3: 0 CRITICAL, 0 HIGH. HIGH, fixed: - FR-029 refused any dispatch not on the annotated tag, against FR-033's branch rehearsal; now the tag and branch-membership checks stand down on a branch, as in the model (release.yml:200-249 at v1.1.0), any other ref is refused, and contracts/workflows.md steps 2-3, T018 and T019 agree - no task ran the wheel check on a bad wheel, though a missing LICENSE is the lead's ruling 1: T015 and T018 now run each workflow's wheel-check heredoc on four synthetic wheels (as built; no licenses/LICENSE; a changed payload byte; a changed mode) - the upload jobs' permissions were "the reads its re-checks need": now exactly id-token: write, actions: read, contents: read (the model's release.yml:691-694, :1133-1136), build contents+actions read, install contents read, held by T018 and T020 - FR-014 let --help behave as in a checkout while FR-012 refuses it on a broken stamp: FR-014 now applies to a stamp that passes FR-010 MEDIUM, fixed: T004's tests run the payload's bash directly, so T007 and T008 stay parallel; FR-024's move is in the v1.1.0 notes (T023) and the coverage table; the PATH note's "none" case has its own ending; a branch rehearsal needs a dispatched tests.yml run first (header, T021); FR-031's "nothing from opensoft/openRepoTools" is listed as met by the absent pypi.org publisher; the 3.9 leg compiles the installed payload's copies. Also: the package job takes tomli's whole entry (39+ hashes) from the build lock instead of copying one digest (research R12); build's outputs name `final`; main is now 83d2690 (lane-start and skills/handoff/SKILL.md changed in content, modes and payload list unchanged). Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…n the change and in feature 006 (#228) Documents only. Each ruling is applied in the change first, then in the feature: 1. A repository guard on the uploads, in code (FR-048; design.md Decision 10; research R19): - opensoft/openRepoTools: testpypi takes a pre-release only, and pypi refuses outright; - opensoft/openRepoTools-code: pre-release to TestPyPI only, final to TestPyPI then PyPI; - any other repository: both upload jobs refuse. The build decides it before any approval and records to-testpypi and to-pypi; each upload job's condition reads them and its first step checks again; the missing pypi.org publisher is the second line. The model's release.yml carries no such guard, so it is new here. T018 adds test_release_guard_build_ and _upload_, and T019-T021 build and document it. 2. The proposal and the pypi-package delta spec now state FR-029's rule: on a branch rehearsal the tag and release-branch checks stand down, as in openRepoShape's release.yml:200-249, and every other check runs (one new scenario). 3. main is not merged now: tasks.md makes that merge, as a merge commit, the implementation's first act. 4. pip's /bin/sh trampoline (pip 26.2.1, distlib/scripts.py:180-182) is recognised as pip's console script (FR-020, Decision 8, pipx-link.md, R6), with three refused and five placed fixtures in T012. pip's own template writes the import at column 0 in both forms (PipScriptMaker, wheel.py:417-424), so the import pattern stands. 5. A package-mode run names `openrepotools <its version>` as the count line's source; `<repo> @ <ref>` is only for a checkout or the one-line install (FR-019, Decision 7, R5). 6. Wording: - the unreadable-stamp clause is now "the openrepotools beside pipx's link, whose stamp cannot be read"; - the broken-stamp line takes <why> as "cannot be read", "is partial:" or "is malformed:", one fixture each in T009; - "venv-shaped" is the one term; - the pypi job is "skipped" in an rc rehearsal; - a branch rehearsal builds with the version of the tag it rehearses, 1.1.0rc1 first (R20, after the model's l3-rehearsal-v1.1.0). The change's tasks.md ticks 2.1 (eb12177) and 2.3 (760281b), and item 4.3 now says skipped. design.md records rulings 6-11 as resolved by the lead, 2026-10-18. /speckit.analyze, two passes: - pass 1 found two MEDIUM, both fixed: T019's verify needed guard-test names that T018 had not fixed, and T009 lacked the three causes. It also fixed four LOW: the data model's install row, the exact-spelling guard, the checklist's scenario count (now 49) and FR-032's compile source; - pass 2 found 0 CRITICAL, 0 HIGH and 0 MEDIUM. 25 tasks (19 [O], 6 [S]); every task line is well formed; openspec validate --strict passes. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…to main before Phase 1 Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ped stamp src/openrepotools/__init__.py holds a docstring and nothing else (research R1), so loading the package runs no code. src/openrepotools/_release.py is contracts/stamp.md's committed file: a module docstring with no line hatch could read as the version, then the five assignments, VERSION at 0.0.0 and TAG, COMMIT, DIGEST and REPOSITORY empty, LF only, with a final newline (#228). Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…24 carries Brett Heap's option (c) (#228) Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… ruling 2026-10-18) src/openrepotools/__init__.py and src/openrepotools/_release.py now open with `# SPDX-License-Identifier: Apache-2.0`, as every other tracked .py file in this repository does and as openRepoShape v1.1.0's own package files do. As in all of those, the docstring follows on line 2 with no blank line between. Every other byte of both files is unchanged, so the stamp is still the SPDX line, one module docstring and the five assignment lines, LF only, with a final newline (#228). T001's verify still exits 0. Hatchling 1.27.0's version pattern still first matches `VERSION = "0.0.0"`, since a `#` line cannot match it. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ring, five assignments (#228) On the lead's ruling of 2026-10-18, src/openrepotools/_release.py opens with `# SPDX-License-Identifier: Apache-2.0` (b6ff505). The documents now say so. - contracts/stamp.md: the committed file's block and its bullets give the SPDX line first, then one module docstring, then the five assignment lines. Grammar rule 2 already skipped every blank and `#` line. It now says outright that this holds before the docstring, so the SPDX line is skipped. Rule 3 now says the docstring need not be line 1, and only lines rule 2 skips may come before it. The hatch section notes that a `#` line can never match hatch's pattern, and the writer keeps the SPDX line with every other byte. - data-model.md: the file's shape is the SPDX line, one docstring and the five lines, and the reader skips the SPDX line as a comment. - research.md R1: __init__.py holds the SPDX line and a docstring and no code. Both package files open with that line, as every tracked .py file here and openRepoShape v1.1.0's package files do. The stamp is that line, one docstring and the five lines. tasks.md, T001's task line included, is the lead's, and is untouched. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…soft/openBenches#165 (#228) Brett Heap's word of 2026-10-18 was "go with (c)". Lane openRepoTools-3 has filed opensoft/openBenches#165, for workBenches' scripts/setup-estate-commands.sh to accept pipx's openRepoTools link. - spec.md FR-047 is decided, no longer pending. README offers `pipx install openrepotools` only after opensoft/openBenches#165 lands, and PyPI must still serve the version (FR-045). Until #165 lands, README says a workstation uses one install route or the other, never both, and cites it. - proposal.md: the workBenches condition's position (c) bullet is decided and cites opensoft/openBenches#165. It is the only proposal bullet that changed. - design.md: the workBenches question leaves "Still open". It is now item 12, "Resolved by Brett Heap, 2026-10-18: (c)". - the change's tasks.md item 1.4 is ticked, with its evidence. The issue is written in full as opensoft/openBenches#165 throughout, because a bare #165 in this repository names #165. Feature 006's tasks.md is the lead's and is untouched. T024 already carries the README sentence (cf43b07). `openspec validate release-tags-pypi --strict`: Change 'release-tags-pypi' is valid. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…wheel.md The build system is pinned at hatchling==1.27.0. [project] names openrepotools, with a dynamic version read from src/openrepotools/_release.py, requires-python >=3.9, Apache-2.0 with license-files ["LICENSE"], dependencies = [], and no readme. It declares the one script, openRepoTools = openrepotools.cli:main, and the wheel's packages, src/openrepotools. The force-include map has 24 entries. The first 23 are the installer's payload_names, in its own order, and the last is contracts/openreposhape-pin.yaml. Each entry maps P to openrepotools/payload/P. Header comments in openRepoShape v1.1.0's style give three reasons: - src/, because the root's openRepoTools clashes with an openrepotools/ directory on a case-insensitive disk; - no readme, because README.md goes to the assembly root at the cutover; - the hatchling pin, because 1.27.0 is the newest release on Python 3.9, and 1.28.0 and later require 3.10, as read from PyPI. The optional description, authors, classifiers and [project.urls] are left out. contracts/wheel.md allows them, but this task does not ask for them. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…outs The four fixture builders that plan.md's "The test layout" names, for the pipx, stamp and entry-module tests (T004, T005, T009, T012, T018). The module imports only the standard library, never conftest, and finds the repository as Path(__file__).resolve().parent.parent. - package_tree(prefix, python="python3.12", stamp=None) builds <prefix>/lib/<python>/site-packages/openrepotools/ and returns its payload/. It copies every src/openrepotools/*.py that exists, at 0644, with the given stamp text as _release.py when one is given. payload/ holds the 24 files of pyproject.toml's force-include map, in its order, byte for byte, at 0755 or 0644 by the checkout's owner-execute bit. - pipx_venv(pipx_home, release, python=None, stamp=None) builds <pipx_home>/venvs/openrepotools/ around a package_tree for pipx 1.11.1, 1.17.8 or 1.18.3, defaulting to the interpreter of that release's row in contracts/pipx-link.md. It writes bin/openRepoTools as pip's console script naming the venv's bin/python, and pipx_metadata.json and pyvenv.cfg with placeholder content. Under a spaced home, the console script is pip's /bin/sh trampoline, as pip writes it there. - console_script(path, python, form=None) writes pip 26.2.1's PipScriptMaker template for openrepotools.cli:main, at 0755. It writes either form pip writes: form="shebang", form="trampoline", or pip's own choice, with distlib's quoting of a spaced interpreter and Linux's 127-byte limit on every platform. - stamp_text(**fields) gives the committed stamp with the given fields' values. Each committed line must occur exactly once, and every other byte is kept. Values are not checked, so broken stamps can be built. The payload list is read from the force-include table line by line, because Python 3.9 has no tomllib, and it is cross-checked against tomllib where tomllib exists. The list is read when a builder is called, not at import. A malformed map then fails that builder, and test_payload_map_ still runs and names the differences. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Takes in #232 (tests/run.sh records its lock owner), #233 (the openRepoShape pin at v1.1.0, 190133d) and #229 item 22 (the bench-root host-path hygiene rule). The two sides touch disjoint files, and no file this branch adds names a bench-root path. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…offline package install (US1) The US1 tests of contracts/pipx-link.md and contracts/cli-output.md, written before T008, on tests/package_layout.py's fake venvs: - test_pipx_link_*: the twelve layouts (pipx 1.11.1, 1.17.8 and 1.18.3 under $PIPX_HOME, ~/.local/pipx, ~/.local/share/pipx and a home with a space, absolute and relative links, PIPX_HOME set only in its own column); a 40-link chain at the hop limit; the five negative cases, from a checkout and from a package outside pipx's venv. - test_pipx_skip_*: the exact skip and pipx-own count lines, 28 receipt rows and the link left as it was; a second link refused with today's rm -f for it alone; the venv-shaped entry and paragraph with no rm for the link, alone and beside another link; no jq; a restart retirement; a later --install; RETIRED never holding openRepoTools. - test_pipx_offline_*: a package-mode --install with the sentinel repository and a failing gh and curl places what a checkout's install places, apart from the link, and calls neither. Every run is bash <installer> --install, never the console script. Only the lines the contracts name are asserted, never a whole output or a hook line. Before T008, 27 fail on today's link refusal and 7 pass. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…228) Add test_the_package_imports_only_the_standard_library. It parses every module under src/openrepotools/ with ast and holds each import, at any depth, to an explicit allowlist of top-level names: os and sys, the two modules design.md Decision 3 has the entry module use (os.execvp, sys.argv, sys.stderr). A relative import and an __import__() call are refused. Where sys.stdlib_module_names exists the allowlist is itself checked against it; on Python 3.9, which has none, nothing skips and the allowlist alone decides. Widen test_the_python_files_compile to compile the same set of modules. Lane: openRepoTools-3 Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…the_ref It now says that a checkout and the one-line install name the repository and ref they fetch from, and that a package names its release (contracts/cli-output.md). Every assertion of the three test_version_* tests is unchanged. Lane: openRepoTools-3 Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…built wheel and the console script The package's tests come before their implementation (specs/006-release-pypi, tasks.md T005), under plan.md's four prefixes: - test_metadata_*: contracts/wheel.md's pyproject.toml rules, read with tomllib or tomli, skipping by name where neither imports. The build-lock agreement skips until .github/release-build-requirements.txt exists. - test_payload_map_*: the force-include map against payload_names, run from the installer's own text, plus the openRepoShape pin, both ways round. - test_wheel_*: checks 2, 3, 5 and 6 of contracts/wheel.md and the member comparison against HEAD, on the wheel OPENREPOTOOLS_TEST_WHEEL names; skipped by name when it is unset. Check 6 is also held the other way, so a member the list has and the wheel lacks is named. - test_entry_*: pip's console script in a venv --without-pip holding a package_tree: the exec of the first bash on PATH in the script's own process with the payload and the arguments unchanged; a refused argument as the payload's own refusal in both of pip's script forms; a SIGTERM mid-placement leaving no temporary; the exact no-bash refusal, exit 2, nothing run; and wip_shape_ref, cut out with installer_function, reading the pin packaged beside the payload. Before T007 every test_entry_* fails on "No module named 'openrepotools.cli'", and nothing else. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… worktree and cherry-picked here (#228) Built in parallel on Brett Heap's word of 2026-10-18T03:36:47Z, each from 4ae999d, each accepted on model, scope and verify in its own tree, then cherry-picked with an identical patch-id: - T006: d5449c6 (006-release-pypi-t006) -> d57b75d, accepted 05:58:12Z (sonnet-xhigh) - T010: 331e095 (006-release-pypi-t010) -> fa44864, accepted 08:44:12Z (sonnet-xhigh) - T005: c862db2 (006-release-pypi-t005) -> b286953, accepted 08:46:35Z (opus-xhigh) T004 (7921a2e) is marked once its own acceptance has run. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…s and its stamp writer (#228) The tests come before the workflow (US5, ahead of T019 to T021), so every test that reads .github/workflows/release.yml fails until it exists, naming the file and the tasks that write it. The lock tests and the digest-label test read nothing of it and pass now. Without the submodule the YAML tests skip, as the command tests do. What is run, not only read, each step as GitHub runs a bash step, with every GITHUB_*, RUNNER_*, LANES_* and TMUX* variable removed and gh and curl faked: the repository guard under every row of contracts/workflows.md's table, each upload job's first-step guard, the version check, the ref and branch steps under the rehearsal rule, the gate on tests.yml's four jobs and the digest step under fake forges (the digest step also in a copy of the checkout whose standard or pin names another definition), step 13's wheel check on synthetic wheels made from HEAD's blobs, and the stamp writer, read back by --version from a package_tree. The steps adapted from openRepoShape v1.1.0 are found by the model's own step names (prefixes); the guard by the build outputs to-testpypi and to-pypi; each upload guard as its job's first step. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit 2e19bb85438363e731d9d36e6107f20b7bf6b816)
…om openRepoShape v1.1.0 (#228) The new .github/workflows/release.yml: a dispatch with a `version` input as the only trigger, `permissions: {}`, the `release` concurrency group without cancelling, bash by default, and VERSION and PYTHONUTF8 in `env`. Its `build` job is contracts/workflows.md's steps 1 to 14, the model's steps under the model's names, with design.md Decision 10's differences: - step 1 accepts X.Y.ZrcN beside X.Y.Z (never 0.0.0), and is the repository guard (FR-048), recording `to-testpypi` and `to-pypi` as job outputs; a ref that is neither a tag nor a branch is refused; - the checkout takes the submodule and full history, so the ref step fetches the tag without `--depth`; - the gate names tests.yml's four job ids; - the digest is the pinned submodule's, and its definition is held to the literal sorted-ls-tree-r-v1 and to the pin's digest_definition; - the stamp writer writes five fields, REPOSITORY from GITHUB_REPOSITORY, reads TAG and COMMIT from the environment, and checks both files before writing either; - the wheel check covers openrepotools/payload/ by pyproject.toml's force-include, blob and mode, and names a missing member instead of crashing. The testpypi, install and pypi jobs (T020) and the RELEASING header (T021) follow. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit 853dafff3df5b8b5c06da46be623146e736da5cf)
…nRepoShape v1.1.0 (#228) TestPyPI, then the install check, then PyPI, per contracts/workflows.md: - testpypi and pypi each hold exactly id-token: write, actions: read and contents: read, in their own environments, and run only on a v* tag where the build's record says so (to-testpypi, to-pypi), so pypi is skipped in an rc rehearsal; - each upload job's first step is the repository guard again (FR-048), from the tag v<version> alone: TestPyPI takes any release from opensoft/openRepoTools-code and a pre-release alone from opensoft/openRepoTools, and PyPI takes a final from opensoft/openRepoTools-code and nothing else; - after the guard, the model's steps as they are: the artifact and its sha256, the environment's rules, this run's approval and the tag read again, an index holding no file of the version but the verified wheel, the upload by pypa/gh-action-pypi-publish@dc37677, and the served digest read up to 20 times; - install: ubuntu and macOS on 3.x and ubuntu on 3.9, with no Windows leg. The wheel comes from TestPyPI by its digest on a tag and is the build's artifact on a branch. pipx comes from its hash lock and places the one link, and --version is checked line for line. The offline --install is set up as tests.yml's package job sets up its own, with the exact skip and count lines and 28 receipt rows. It runs again on macOS under /bin/bash 3.2, and the 3.9 leg compiles the installed payload's lanes-index and lane-worktrees. The RELEASING header (T021) follows. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit 59c3aa0b958ffa54b1b1ef70307cd57600ea1795)
… sections (#228) The header comment alone, in the model's form; the jobs are unchanged. Its six sections, in order: 1. what the workflow does and its four jobs, adapted from openRepoShape v1.1.0 (190133d), with design.md Decision 10's differences named, among them the install check's rerun under macOS's /bin/bash 3.2; 2. the procedure, on Brett Heap's word: the CI wait, the annotated tag with v1.0.0's message form (FR-036), the dispatch, the two approvals, gh release create after PyPI serves the version, then release/vX.Y at vX.Y.0; 3. opensoft/openRepoShape#850's branch and tag policy: the trunk, annotated tags never moved or reused, release branches, back-ports, the lanes' side and patch tags; 4. the two rehearsals, and never 1.1.0 (FR-033): the branch rehearsal with 1.1.0rc1 first, tests.yml dispatched on the branch first, and the TestPyPI rc rehearsal with pypi skipped; 5. where releases come from: the code leg from v1.1.0, the repository guard's table (FR-048), the missing pypi.org publisher, the code leg staying public for the tag fetch, and Brett Heap's environments, ruleset and publishers; 6. what the workflow never reads (FR-046). Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit 848e58d867fe9ec810711c49c43863b6082890fc)
…fied wheel at its digest (#228) Lane: openRepoTools-3 Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> (cherry picked from commit 0a40d4c76f8ab19ec0b673e3db9811ae31098078)
Each accepted by the lead on model, scope and verify, then picked with an identical patch-id: T018 2e19bb8 (accepted 19:22:14Z), T019 853daff (19:48:02Z), T020 59c3aa0 (20:34:13Z), T021 848e58d (20:48:18Z). The docs commit before this one records the lead's ruling on the empty-index check. Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…dy, byte for byte (#228) Lane: openRepoTools-3 Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> (cherry picked from commit 71a8615ad8fe64b3c4bfc883138020f9e64251a9)
…e package on PyPI, --version naming the release, pipx's link skipped, the hook pair that waits for its target (#237), the package job and release workflow, the move from the one-line install, and a closing Before the tag checklist for every placeholder (#228) Lane: openRepoTools-3 Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> (cherry picked from commit 4f720e60bf55cb9c32832c4ace5b80de7523b112)
…a workstation with pipx's link sees The version paragraph no longer says there is no version number. It says a release is an annotated tag, the version comes only from the tag, and shows the stamped, unstamped and checkout --version first lines (FR-043). For a workstation with pipx's link: the file count says sixteen beside it, the symlink passage names pipx's openRepoTools as the one link skipped, and the count invariant adds twenty-eight placed, one left to pipx and 28 receipt rows, the hook pair still on top (FR-044). One sentence beside the install routes says a workstation uses one route or the other until opensoft/openBenches#165 lets setup-estate-commands.sh accept pipx's link (FR-047). No pipx install route is added (FR-045). README is 505 lines, so test_readme_is_short_enough_to_be_read gets a dated entry: 486 -> 505 here and 510 -> 529 at an assembly root. The lead widened T024's files: to tests/test_test_roots.py, whose length-caps test pins those numbers, so its fixtures and docstring move to 529/530 and 505. Verify: the pipx guard passes; bash tests/run.sh -k 'repo_hygiene or readme' gives 193 passed; the roots test passes. Lane: openRepoTools-3 Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> (cherry picked from commit 7687bf52a791e28abfc5e283b2e0a7017caa3b45)
…ots.py (#228) Each accepted by the lead on model, scope and verify, then picked with an identical patch-id: T022 71a8615, T023 4f720e6, T024 7687bf5. T024 moves the cap fixtures in tests/test_test_roots.py with README's new length, outside the files: its task line named; the lead ruled that in on 2026-10-18, and its files: now say so (its verify: 193 passed; the roots test: 1 passed). Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ed, the one-route sentence names both routes, and the v1.1.0 notes name #247 (#228) S1: the assembly's README cap goes back to 510. assembly-0001's README part no longer applies (its hunks at :237 and :300 fail against T024's rewrite and #247's count paragraph), so 529 was arithmetic over a patch that does not apply; the re-cut sets the assembly's cap, as the 2026-10-18 AGENTS.md entry says for its 347. T024's dated entry says so, and tests/test_test_roots.py goes back to 510 and 511 with its docstring's numbers made true at this head (330 and 505 standalone; 347 and 510 at an assembly root). S2: test_readme_says_what_a_release_is_and_offers_no_package_route reads README and holds: no line matches pipx or pip install before openrepotools in any case; the install section cites opensoft/openBenches#165; the version paragraph holds the three --version first lines; and 16 of 17 and 28 receipt rows stand beside pipx's link. The reviewer's mutants M1 to M4 and M6 each fail it. S3: README's FR-047 sentence names the two routes it rules between, pipx's openrepotools and workBenches' ./setup.sh, in the same three lines (README stays at 505). S4: the v1.1.0 notes fill <#237 PR> with #247, say that our exact guard entry is taken back out of a file that carries it while the pair is deferred, and rewrite the stale checklist item for a PR that had not landed. Lane: openRepoTools-3 Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…ame tomli, and AGENTS.md says what the one bash 3.2 run is (#228) S1: .github/release-build-requirements.txt's header said the build lock is the one record of tomli's digests and that a resolution moving tomli moves the package job's too. The pipx lock carries the same tomli entry byte for byte, and the package job installs it in step 7, after step 4's tomli, so the package tests run on the pipx lock's. The header now says the two entries must move together, re-resolved in one act; research R12's rationale says the same. Only the header changed: every line from the first package line on is as it was, so T014's verify still holds. S3: AGENTS.md's CI paragraph now says that from PR 3 the release workflow's macOS install leg, on dispatch only, runs `openRepoTools --install` under /bin/bash 3.2, the one 3.2 run anywhere and no other command, and the bash 3.2 paragraph says "nothing but your own care holds it" again. The file stays at 330 lines, the hygiene test's cap. Lane: openRepoTools-3 Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…ck carries the same tomli (#228) The comment above the package job's test-tools step said the build lock stays the one record of tomli's digests, and the docstring of test_tests_yml_holds_no_digest_of_its_own said the build lock is the one record. Both repeated the claim the build lock's header no longer makes: the pipx lock carries the same tomli entry, byte for byte, and step 7 installs it after step 4's tomli, so the package's tests run on it. The comment now says that, in the same seven lines, and the docstring says the same. Comment lines and a docstring only: no YAML key, value or step and no test code changed. Lane: openRepoTools-3 Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Lane: openRepoTools-3 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… and names every assembly-0001 README hunk that fails (#228) The re-check of PR 4's fix round (lane openRepoTools-5, #228 comment 6267650575) found one SHOULD and one NIT, both in T024's dated entry of test_readme_is_short_enough_to_be_read. The heading said "486 -> 505 HERE AND 510 -> 529 AT AN ASSEMBLY ROOT", but the entry's own last paragraph says the assembly's 510 does not move. It now reads "486 -> 505 HERE, on 2026-10-18", the form of the AGENTS.md entry's heading. The sentence naming the failing hunks of assembly-0001's README part named two. git apply --check, hunk by hunk from the tree root, shows three fail at this head: :237, :260 and :300. Before T024 (ed72edf^), :237 and :260 applied and :300 did not. The sentence now names all three, each with what it changes and what it fails against, and "neither" becomes "none of the three". Lane: openRepoTools-3 Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
Sorry @brettheap, you've used your own review budget of 250,000 diff characters for the last 7 days. You can request another review in 2 days by commenting |
Reviewer's GuideThis PR completes the release-record documentation work by preserving the v1.0.0 notes, drafting the post-PyPI v1.1.0 notes, documenting release/version and pipx-link behavior in README, and adding tests and task metadata to protect those contracts. Sequence diagram for pipx installation and --install behaviorsequenceDiagram
actor User
User->>pipx: pipx install openrepotools
pipx-->>User: openRepoTools link in pipx environment
User->>Tool: openRepoTools --install
Tool->>Tool: inspect ~/.local/bin/openRepoTools
alt pipx link found
Tool-->>User: skip link, 16 of 17 placed, 1 left to pipx
Tool-->>User: write 28 receipt rows
else regular file or no link
Tool-->>User: place 17 files and write receipts
end
State diagram for release version reportingstateDiagram-v2
[*] --> Checkout
Checkout --> UnstampedPackage: build package from checkout
Checkout --> RepositoryInstall: one-line install
Checkout --> TaggedRelease: annotated tag vX.Y.Z
UnstampedPackage --> VersionZero: --version prints 0.0.0
RepositoryInstall --> RepoRef: --version prints repository and ref
TaggedRelease --> ReleasedPackage: release build stamps wheel
ReleasedPackage --> ReleaseVersion: --version prints version, repository and commit
Flow diagram for the release record and PyPI publicationflowchart LR
Tag[Annotated tag v1.1.0] --> Build[Release build stamps version into wheel]
Build --> TestPyPI[Upload to TestPyPI]
TestPyPI --> InstallCheck[Install checks pass]
InstallCheck --> PyPI[Upload to PyPI]
PyPI --> GitHubRelease[Create GitHub Release from v1.1.0 notes]
Draft[Draft v1.1.0 notes] --> GitHubRelease
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
This was referenced Oct 19, 2026
|
brettheap
added a commit
that referenced
this pull request
Oct 21, 2026
… 1.1.0 and list, by area and from the squash titles of aaa7bc8..a42946e, what else changed on main since v1.0.0 (#228) (#293) Part of #228. It brings `docs/release-notes/v1.1.0.md` up to date on main: first on `a42946e`, as lane 3 asked on Brett Heap's word (#228 comment 6303608345, the section for lane openRepoTools-2, task 1), then with lane 3's review of `d8a349d` (comments 6314185715 and 6314529807 on this pull request), with the lines for the three changes that landed after `a42946e`, and with the line for #296, which landed right before this pull request. It is one file, changed in two commits (`d8a349d` and `bebb77d`), 59 insertions and 4 deletions against main. Lands last before rehearsal D's freeze; lane 3 reviews and merges it (#228 6303608345) **What changed** - **Lane 3's review is applied,** in the second commit: - **The line on #255 and #271** no longer says that `lane-reconcile` and `lane-handoff` read a dependency nested in a leg, since only the sweep and `lane-end` do. It says that a leg directory this account cannot search is unreadable and never `absent`; that a dependency nested in a leg whose directory, or one above it, it cannot search is unreadable to the sweep and `lane-end` too; and that one known gap remains, #272, where the sweep reads a declared leg beneath such a directory as `absent`, so `lane-end` does not hold on it. It also says NOT POLLED where the tool prints it, and it says that the item closes two gaps in #246, where it said "both gaps" with nothing before it to refer to. - **The line on #280 and #283:** an `awk` exits and does not "return", and the sentence on a status of 0 or 8 is gone, because a reader of the notes cannot act on it. - **The line on #214:** the fence passes a local commit only when it adds or changes a register or handoff file, and never checks whose it is, so the line no longer says "the lane tooling's own". - **The counts in the `<other-changes>` item:** the pin's line (#233) is in the list, so the list carries 44 of the 53, and the other 9 have their lines under "What 1.1.0 adds", not 43 and 10. The item says "the openRepoShape pin" where the runner pin of #296 could be taken for it. - **The milestone item** names #247, so it lists the six entries the milestone held on 2026-10-20. - **#209 is not tests-only.** Its `-e` fixes `lanes`' stderr filter under macOS's BSD `grep`, so it moves from the test suite to the lane area, after #208's, and its one line there also carries its test changes: the `repoG#8` assertion and the count of bash files in prose. It is cited once. - **Lines for the changes after `a42946e`:** #263 (`d9065df`), #289 (`fb2cf36`) and #294 (`acc89ea`, which closes #292) landed on 2026-10-21, from 11:28Z to 11:30Z. Each has a line in its area, worded from its squash commit and its description: #263 and #289 under "The register and `lanes-edit.sh`", and #294 under "`lane`, `lane-start`, `lane-end`, the name guard and their helpers". - **#296 has its line too,** last under "The test suite and its checks": CI and the release workflow run on `ubuntu-24.04`, because `ubuntu-latest` is now Ubuntu 26.04, and `macos-latest` is unchanged. It landed right before this pull request, as `5afba4a`. - **"What 1.1.0 adds" gains two lines,** after the annotated-tags item. They are for the three entries that closed in the v1.1.0 milestone after the draft was written: - **#255,** fixed by #271: the lane tools name what they could not read in a triad's legs. `lane-handoff` names every tree-inventory record that is not a whole schema-1 one, and a leg directory this account cannot search is unreadable and never `absent`. Only the sweep and `lane-end` also see a dependency nested in such a leg, since `lane-reconcile` and `lane-handoff` read declared legs only, and #272 stays open as the known gap. - **#280,** fixed by #283: `lane-handoff` reads the lane's lifecycle whole and parses it afterwards, so an `awk` that exits early can no longer turn `lane-state`'s SIGPIPE into a lifecycle that could not be read. - #283 is #280's pull request, so the three numbers make two lines. Each line cites the issue and its pull request, as the hook-pair line does for #237 and #247. - **"What else changed since v1.0.0" is drafted** from `git log aaa7bc8..a42946e`, which is 53 squash commits, one pull request each and no merge commit. It is grouped by area, one line each, and each line ends with its pull request. It lists 44 of the 53: the pin's line (#233) at its head and 43 by area, as 4 on the estate commands, 10 on the register and `lanes-edit.sh`, 11 on `lane`, `lane-start`, `lane-end` and the name guard, 6 on the handoff and its skill, 1 on the lane tools in a triad's legs (#246), 9 on the test suite and its checks, and 2 on the triad migration's records. - **The other 9 are accounted for elsewhere:** the package series of #228 (#262, #267, #268, #269, #270 and #284) is covered by #228's lines, and #247, #271 and #283 have the lines above. - **The lines added on 2026-10-21** are for the four changes after `a42946e`: #263 and #289 on the register and `lanes-edit.sh`, #294 on `lane`, `lane-start`, `lane-end` and the name guard, and #296 on the test suite and its checks. The areas now hold 47 lines, one for each of 47 pull requests, and #233's line at the head of the list makes 48. - **The list is redone at the tag.** It is drafted from the squash titles only. - **"Before the tag" is updated in three items:** - `<pr-count>` gives the count at `a42946e`, which is 53; - `<other-changes>` says what was drafted, which 9 pull requests have their lines under "What 1.1.0 adds", that the lines for #263, #289, #294 and #296 were added on 2026-10-21, and what is left to do at the tag; the placeholder's own line now stands for the changes after `a42946e` that have no line above; - the milestone item names the six entries the milestone held on 2026-10-20: #228 still open, #237 closed by its pull request #247, #255 closed, and #280 closed by its pull request #283. **Not added:** nothing that has landed. #296 landed right before this pull request and has its line. This pull request itself, and whatever lands after it, is what the `<other-changes>` placeholder stands for. None of #263, #289, #294, #296 and #292 is in the v1.1.0 milestone, which still holds the six entries of 2026-10-20. **How this keeps the draft's rules** - **One-line paragraphs:** every added line is its own list item, and none is wrapped. - **References:** every reference above "Before the tag" is spelled `opensoft/openRepoTools#N`, with no bare `#N`, since the notes are published from another repository after the migration. - **Placeholders:** `<other-changes>` stays as a named placeholder in code font, as the closing line of the list and as its checklist item. `<pr-count>` is unchanged apart from the drafting-time count. - **The file's closing lines are untouched:** the self-naming last line stays last. **Tests** - **T023's verify command** passes: the last line names `openRepoTools-spec` and `docs/release-notes/v1.1.0.md`, `## Before the tag` is there, and so is `pipx install --force openrepotools`. - **Coverage:** a script over `git log aaa7bc8..acc89ea`, 56 commits and no merge, finds each pull request cited above "Before the tag" except the six of #228's package series, which #228's lines cover. That is 46 by area, #233 at the head of the list, and #247, #271 and #283 under "What 1.1.0 adds". #296 is not in that range, and its line cites it. - **Hygiene:** by grep over `tests/`, no test names this file. The two that read its content scan every tracked file, and both are in `tests/test_repo_hygiene.py`. The only other test that names `release-notes` is in `tests/test_release_workflow.py`, and it reads `release.yml`, not the notes. All of `tests/test_repo_hygiene.py` was run on the file, through `tests/run.sh` with every `LANES_*` and `TMUX*` variable unset: ```text -k 'repo_hygiene' -v collected 2933 items / 2696 deselected / 237 selected 237 passed, 2696 deselected in 2.59s ``` - **Not run:** the whole suite. CI's `tests` job is the suite of record. This pull request's own runs on `bebb77d` went red on `ubuntu-latest`, which is Ubuntu 26.04, for the reasons #296 gives, because #296 was not yet on main. The record is lane 3's queue run over main, #296 and `bebb77d`, on `ubuntu-24.04` (below). **Where the draft's rules left room, and lane 3's answers (comment 6314185715)** - **Which section holds #255 and #280:** "What 1.1.0 adds", because the milestone is Brett Heap's scope for the release and #237 with #247 already sit there. - **`<other-changes>` stays** as a closing placeholder after the drafted list, since this pull request itself lands after `a42946e`. - **How much to list:** the tests-only and migration-record lines stay through the tag, because the check that every pull request has a line depends on them. If Brett Heap wants a shorter body, they fold into one line that still lists every pull request number. - **Issues and pull requests:** the milestone lines cite both, and the area lines cite the pull request only. **Lane 3's re-check of `bebb77d`** (#293 6315668503) is MERGE AFTER FIXES. - **What holds:** every line lane 2 listed, the recount behind line 140 (44 of the 53 pull requests in `aaa7bc8..a42946e`, and 56 in `aaa7bc8..acc89ea`), the file's rules, and T023's verify commands. - **One SHOULD and two NITs, all wording:** - line 45's sentence on a dependency nested in a leg, where "one above it" reads as a directory above the leg, which is #272's case. The text was lane 3's own; - "One known gap" in the same line; - line 74's last clause. - **Why they wait:** lane 3 merges the notes as tested and carries the three fixes into the notes' final pass at the tag. A push here would cost another CI round while lane 2 is out of usage until 15:30Z, and the notes are edited again at the tag in any case. Lane: openRepoTools-2 Landed by lane openRepoTools-3, as queue prefix `lane3-queue-u/p2-293` (tree `9b879ca`; tests.yml run 39595166877, green on `ubuntu-24.04`), right after #296. Before the landing, lane 3 merged main into the branch, so that its own checks ran over main with #296; the content is unchanged. Brett Heap's word, of 2026-10-20T22:5xZ: "merge all when green for all merges thru v1.1.0. use this for all lanes" (#228 6303614082). Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #228: pull request 4 of 4 of feature
006-release-pypi, plan.md "Delivery". It holds User Story 6, which is Phase 8 ofspecs/006-release-pypi/tasks.md(T022 to T024).The record now tells the truth about releases. The v1.0.0 notes are in the repository, the v1.1.0 notes are drafted, and README says what a release is, what
--versionprints, and what a workstation with pipx's link sees.Nothing is published here. The v1.1.0 notes are a draft with placeholders, and the GitHub Release is made from them only after PyPI serves 1.1.0 (
.github/workflows/release.yml:108-112). README gives no install command for the package (FR-045). Every tag and upload still waits for Brett Heap's word (plan.md gate G8).What it adds
docs/release-notes/v1.0.0.md(T022,d637841): the published v1.0.0 Release body, byte for byte. It is exactly the output ofgh release view v1.0.0 --repo opensoft/openRepoTools --json body --jq .body(research R15).cmp - docs/release-notes/v1.0.0.md. One command wrote the file and checks it, so the two cannot disagree about a trailing newline. The suite does not repeat it, because it reaches no network.git show --stat). It is the Release body plus the one newline--jqadds (review N1).docs/release-notes/v1.1.0.md(T023,cb478cc): the draft v1.1.0 Release body, 90 lines. The Release is created from it after PyPI serves 1.1.0, so the notes never name a version PyPI lacks.## What 1.1.0 addswith six items (the package on PyPI asopenrepotools;--versionnaming the release;--install's rules for pipx's link and pip's console script; the hook pair that waits for its target, Fresh install activates Claude name-guard hook before workspace linking supplies its target #237; thepackagejob and the release workflow; releases as annotated tags),## What else changed since v1.0.0, and## Install and upgradewith seven items. The install section gives the move from the one-line install,pipx install --force openrepotoolsthenopenRepoTools --install, and why--forceis needed.<name>in code font. Each is listed in the closing## Before the tagchecklist, which has 11 items: eight for the placeholders (the tag time and the tag words share one) and three for facts to re-read, with no placeholder (the hook pair, the pin, the milestone).opensoft/openRepoTools-spec'sdocs/release-notes/v1.1.0.md.ed72edf): what a release is, what--versionprints, and what a workstation with pipx's link sees. README grows from 485 to 505 lines (wc -lat29cc1b3and at9378103), and gains no install command for the package.README.md:361-367): a release is an annotated tagvX.Y.Z, and the version comes only from the tag. The release build writes it into theopenrepotoolspackage, whose--versionfirst line isopenRepoTools <version> (<repository> @ <commit>). A package built from a checkout printsopenRepoTools 0.0.0 (an unstamped package). A checkout and the one-line install printopenRepoTools (<repo> @ <ref>), as before (FR-043). This replaces "There is no version number here".:240-242): a workstation uses one install route or the other, never both, until setup-estate-commands.sh: accept pipx's openRepoTools link, as openRepoTools --install will (opensoft/openRepoTools#228) openBenches#165 letssetup-estate-commands.shaccept pipx's link (FR-047, Brett Heap's decision of 2026-10-18).:244);--installskips is pipx's, atopenRepoTools(:267-268);16 of 17 placed in <dir>, and 1 left to pipx(:271-276);:315-318).tests/test_repo_hygiene.py: README is now 505 lines, sotest_readme_is_short_enough_to_be_readgets a dated entry (2026-10-18), and its cap goes from 486 to 505. The assembly's 510 does not move (review S1).tests/test_test_roots.py: the lead widened T024'sfiles:to it on 2026-10-18. After the fix round it changes one docstring.90794a3):specs/006-release-pypi/tasks.mdmarks T022 to T024 done, and addstests/test_test_roots.pyto T024'sfiles:.What only becomes true at the v1.1.0 tag and the PyPI upload, or at a later step. README gives no install command for the package. These places name the package, the release or a later step in the present tense:
docs/release-notes/v1.1.0.md:5-7and:11: v1.1.0 "puts openRepoTools on PyPI", and is published fromopensoft/openRepoTools-codeafter the migration (Triad migration (feature 004-migrate-to-triad): execution tracking under Brett Heap's word of 2026-10-07 #186).docs/release-notes/v1.1.0.md:14,:53and:57:pipx install openrepotools,pipx install openrepotools==1.1.0andpipx install --force openrepotools. They work once PyPI serves 1.1.0, which is why the file is a draft.docs/release-notes/v1.1.0.md:90: the file's own path in the spec leg, which the cutover makes.README.md:240-241: names pipx'sopenrepotoolsas one of the two routes, and gives no command. The notes':7has 1.1.0 as the first version on PyPI.README.md:271-272: "a link into pipx'sopenrepotoolsenvironment". Such a link exists on a workstation that has installed the package with pipx.README.md:361-364: "The release build writes it into theopenrepotoolspackage it builds". That build is PR 3'srelease.yml, and its first run is a later step, on Brett Heap's word.tests/test_repo_hygiene.py:2536-2538: the new README test says "FR-045's later PR (the change's tasks.md 6.4) rewrites this test", because that PR adds the pipx route to the assembly's README.tests/test_repo_hygiene.py:2510-2513andtests/test_test_roots.py:367-368: the re-cut ofassembly-0001sets the assembly's caps. That is lane openRepoTools-1's step.Runs
b0711af, branchlane3-queue/q4d-228pr4-on-q3d: q3dba4a3df, which holds PR 3 at its fix head, + this head26e5d9a, on main00d52ae, treec124960):tests.ymlrun 39302693633, pending. This is the run of record for the landing.26e5d9a, on PR 3's earlier head1b41ce7. PR 4's diff touches no file of PR 3's two fix rounds (.github/workflows/release.yml,tests/test_release_workflow.pyand design.md), so the rounds and this PR share no file.Review. An independent adversarial review (Opus) gave LAND after fixes, with no MUST and five SHOULDs (
briefs/rv-pr4-006-final.mdin lane 3's tree). It read T022 to T024 as they stood before the fix round.3efcd71:assembly-0001no longer applies (its hunks at:237,:260and:300fail), so 529 was arithmetic over a patch that does not apply. T024's dated entry says so, andtests/test_test_roots.pyis back to 510 and 511 with a docstring whose numbers are true at this head;test_readme_says_what_a_release_is_and_offers_no_package_routereads README. It holds that no line matches(?i)\bpipx?\s+install\b.*\bopenrepotools\b, that the install section citesopensoft/workBenches#165, that the version paragraph holds the three--versionfirst lines, and that16 of 17 placed in <dir>, and 1 left to pipxand28 receipt rowsstand;openrepotoolsand workBenches'./setup.sh, in the same three lines, so README stays at 505 lines;<#237 PR>withopensoft/openRepoTools#247, say that our exact guard entry is taken back out of a file that carries it while the pair is deferred, and turn the stale checklist item into a re-read item.90794a3already records T024's widenedfiles:.main08e7550with PR 1's head77d04aamerged and the three T022 to T024 commits picked on it, each with the patch-id of its original: T022'scmpsilent; T023's three greps pass; T024's guard passes andbash tests/run.sh -k 'repo_hygiene or readme'gave 207 passed;bash tests/run.sh -k test_test_roots: 40 passed;pipx install openRepoTools;testsjob is the suite of record.The fix round's re-check (lane openRepoTools-5, Opus, #228 6267650575): LAND after one line. S1 to S4 are fixed. The new test fails on mutants M1, M2, M3, M4 and M6, each on the right assertion. With
26e5d9a, PR 4 is LAND by this re-check (#228 6267768154).26e5d9a: T024's dated entry was headed "486 -> 505 HERE AND 510 -> 529 AT AN ASSEMBLY ROOT", against its own last paragraph. It now reads "486 -> 505 HERE, on 2026-10-18".assembly-0001's failing README hunks. It now names all three, each with what it changes and what it fails against.git apply --checkon each hunk alone shows:237,:260and:300fail, and the other seven apply.pip3 install,uv tool installand a command wrapped across two lines through, which is no worse than before; and the count checks read the raw text, so a reflow turns them red.Notes for other work
tasks.mdmark, on26e5d9a. It carries NIT-7's three citation fixes. The handoff's tree inventory names a record it could not read whatever its schema, and a leg directory it cannot search is never read as absent (#246 follow-up, before the cutover) #255 lands after that.Landing: Brett Heap's decision 4 on #228 ("Yes, merge when green (Recommended)"), and his word of 2026-10-18T20:3xZ, "use this as approval to merge when green for all merges thru v1.1.0".
tests.ymlon lane 3's prefix branch, under Runs.26e5d9awith q4d's tree, as a fast-forward, so the tree under review is the tree that was tested.Lane: openRepoTools-3
🤖 Generated with Claude Code
Summary by Sourcery
Record the v1.0.0 release and draft v1.1.0 guidance while aligning README documentation and tests with the release and pipx installation model.
Enhancements:
--version.--install, including route exclusivity, installation counts, skipped links, and receipt invariants.Documentation:
Tests:
Chores: