Loomweave 1.0.0 — Clarion→Loomweave rename, version recut, PyPI packaging#52
Conversation
…plugin) Approach A: two PyPI packages (clarion maturin bin-wheels + clarion-plugin-python wheel), plugin as default dep, standard-4 wheel matrix, PyPI Trusted Publishing, keep cosign GitHub Release tarballs as offline channel. Key finding: plugin discovery is $PATH-only, so a vanilla pip/uvx install can't see the co-located plugin. Design adds a current_exe()-relative discovery level (ADR-021 amendment) as the enabling change. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
7 phases: discovery current_exe() level (TDD) -> ADR-021 amendment -> plugin wheel + version lockstep -> clarion maturin bin-wheel -> CI wheels + Trusted Publishing -> install Node cache-warm + docs -> TestPyPI dry-run gate. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Adds a current_exe()-relative discovery level so a PyPI/venv-installed plugin co-located in the same bin/ is found without being on $PATH. $PATH entries are scanned first (shadowing preserved). World-writable refusal + de-dup unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…xe-aware) doctor's plugin.availability check scanned only $PATH, so a co-located PyPI/venv-installed plugin (found by analyze via discover()) was reported as missing. Use clarion_core::plugin::discover() so doctor matches analyze. Adds an integration test proving a plugin co-located with the clarion binary is discovered with an empty $PATH. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… plan Folds the Clarion->Loomweave rename plan and the PyPI distribution plan into a single sequenced master plan (rename-first, publish-second), since the PyPI package name/version are exactly what the rename changes. Phase A (discovery current_exe() level + doctor real-discovery) already landed; Phases B (atomic rename + recut to 1.0.0), C (PyPI packaging as loomweave/1.0.0), D (infra + publish). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…de-dev/loomweave, suite 'Loom' to be renamed PyPI names loomweave + loomweave-plugin-python reserved (drives the rename). Repo target foundryside-dev/loomweave; DNS loomweave.foundryside.dev. Rename lands before 1.0.0 cut. Suite/federation 'Loom' renamed to a cloth-themed <SUITE> (final pick pending); CLARION_LOOM_* -> <SUITE>_*, not LOOMWEAVE_*. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…e flagship Weft framework › Loomweave (flagship, was Clarion), Filigree, Wardline, Legis (+Shuttle planned). Clears the pending-pick language; CLARION_LOOM_*→WEFT_*. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Standalone task brief for a fresh agent to execute the atomic rename: exact name transformations, do-not-rename traps, cross-product flag-don't-break items, hard constraints (one atomic branch, freeze window, no push), and verification gate. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Atomic product + framework rename (Phase B of the Loomweave 1.0.0 master
plan), plus the test fix that greens the suite under it. Branch is local
only — not pushed, no PR — per the Phase B brief.
Renames
- Product Clarion → Loomweave: 8 crate dirs git mv'd (loomweave-{core,cli,
mcp,storage,analysis,federation,scanner,plugin-fixture}), binary, package
names, docs/clarion → docs/loomweave, .clarion/ → .loomweave/,
clarion.db → loomweave.db.
- Framework Loom → Weft: Loom* types → Weft*, CLARION_LOOM_* → WEFT_*
(env), federation wire layer (/api/loom → /api/weft, X-Loom-* → X-Weft-*,
loom_* JSON fields → weft_*).
- Python: clarion-plugin-python → loomweave-plugin-python, module
clarion_plugin_python → loomweave_plugin_python, share/clarion →
share/loomweave.
- Identifiers: clarion_entity_id → loomweave_entity_id, SEI prefix
clarion:eid: → loomweave:eid:, rule/error prefix CLA- → LMWV-, DB magic
0x434C524E ("CLRN") → 0x4C4D5756 ("LMWV").
- URLs: tachyon-beep/clarion → foundryside-dev/loomweave, docs domain
clarion.foundryside.dev → loomweave.foundryside.dev.
- Version recut 1.3.0 → 1.0.0 (Cargo.toml, all pyproject.toml, plugin.toml,
__version__); Cargo.lock + uv.lock regenerated; CHANGELOG [1.0.0]
re-baseline entry.
Carve-outs left intentionally: Filigree issue IDs (clarion-<hex> /
clarion-sf-), .filigree.conf project_name/prefix, docs/archive/ history,
the two rename-planning docs, the pypi spec (Phase C0). api_version stays 1
(a rename is not a wire-incompatible change).
Federation note: the wire layer was renamed in lockstep on owner
instruction — live federation with Filigree/Wardline is broken-by-design
until those peers rename in step.
Green-the-suite fix (pre-existing, not caused by the rename)
- The fixture's [[bin]] artifact was named loomweave-plugin-fixture, which
matches the loomweave-plugin-* discovery glob. A workspace build drops it
into target/<profile>/ next to the running binary, and Phase A's
current_exe()-relative discovery treats the manifest-less binary as fatal
— which broke `analyze` from a dev build and 5 PATH="" tests. Renamed the
artifact to loomweave-fixture-plugin (off the glob); tests stage it under
its loomweave-plugin-fixture manifest name via copy/symlink so spawn's
basename check still holds. Package name, crate dir, and manifest names
unchanged.
Verification: cargo build --workspace green; cargo nextest run 1164/1164
passed (2 skipped); clippy clean on touched crates; pytest 166 passed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…to-end Lands the automatable, locally-verifiable slice of Phase C (PyPI packaging for Loomweave 1.0.0). Validation that needs a pushed branch (workflow_dispatch) or owner external setup — C5 wheels.yml, C6 publish job, C8 TestPyPI — is deferred; Phase D (register Trusted Publishers, rename GitHub repo, DNS, cut tag) is owner-only. - C0: rename the PyPI design spec clarion→loomweave (git mv + content), recut 1.3.0→1.0.0, share/clarion→share/loomweave, tachyon-beep/clarion→foundryside-dev/loomweave; fix its references in the master plan + Phase B brief. - C3: add crates/loomweave-cli/pyproject.toml (maturin bindings="bin", bins=["loomweave"], depends on loomweave-plugin-python==1.0.0). - C2: extend scripts/check-workspace-version-lockstep.py to also assert the bin-wheel's [project].version == workspace version and that it pins loomweave-plugin-python==<workspace version>; add a --self-test (6 cases). Already wired into ci.yml + release.yml. Local verification (artifacts gitignored, not committed): - C1: `uv build --wheel` plugin wheel ships …data/data/share/loomweave/plugins/python/plugin.toml (path followed the rename). - C3: `maturin build --release` → loomweave-1.0.0-py3-none-manylinux_2_39_x86_64.whl carrying …data/scripts/loomweave. - C4 KEYSTONE GATE: clean-venv install of both wheels; `env -i HOME=/tmp /tmp/lw/bin/loomweave doctor --format json` → plugin.availability ok, "1 language plugin discovered: python" — venv bin/ off the scrubbed $PATH, so discovery came through the Phase A current_exe() level. The one-command PyPI topology works after the rename. - C2: --self-test (6 cases) + live check both green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…weave Extends release.yml (per plan C6 "merge into release.yml after verify") with PyPI Trusted Publishing, reusing the existing `verify` gate and v*-tag trigger. - build-wheels: maturin bin-wheels via PyO3/maturin-action, matrix mirroring build-rust (Linux x86_64 @ manylinux_2_28 + macOS aarch64). Off-matrix platforms keep falling back to the cosign GitHub-Release tarballs. - build-plugin: also builds the pure-Python wheel (was sdist-only) and ships it in the artifact. - publish-pypi: OIDC Trusted Publishing via pypa/gh-action-pypi-publish, publishes loomweave-plugin-python FIRST then loomweave (so the ==1.0.0 pin resolves on first release), environment `pypi`, id-token: write, attestations. Real PyPI ONLY on a pushed v* tag; workflow_dispatch target_index=testpypi runs the Phase-C8 TestPyPI dry-run and can never reach real PyPI. UNVALIDATED until the dry-run: requires Phase D2 (register Trusted Publishers for both projects on PyPI + TestPyPI, env `pypi`/`testpypi`, repo foundryside-dev/loomweave) and a `workflow_dispatch` TestPyPI run (C8) before the first real v1.0.0 tag. Until D2 the job fails the OIDC exchange — fail-safe, cannot mis-publish. Matrix is reduced (2 wheels, not the plan's standard-4); Linux aarch64 / universal2 are a follow-up. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1cd00668ea
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| pipx install \ | ||
| "https://github.com/tachyon-beep/clarion/releases/download/${TAG}/clarion-plugin-python-1.2.0.tar.gz" | ||
| "https://github.com/foundryside-dev/loomweave/releases/download/${TAG}/loomweave-plugin-python-1.2.0.tar.gz" |
There was a problem hiding this comment.
Point web install snippet at the 1.0.0 artifact
For the web docs generated from this 1.0.0 recut, this install command still combines TAG=v1.2.0 from the snippet above with a loomweave-plugin-python-1.2.0.tar.gz URL, while the release workflow and package metadata in this commit publish loomweave-plugin-python version 1.0.0. Users following the hosted getting-started page for the first Loomweave release will hit 404s for the tag/artifact instead of installing the plugin; update this snippet to the same v1.0.0 / 1.0.0 values used in README.
Useful? React with 👍 / 👎.
| publish-pypi: | ||
| name: Publish to PyPI (plugin first, then loomweave) | ||
| needs: [build-wheels, build-plugin] |
There was a problem hiding this comment.
Gate the GitHub Release on PyPI publishing
On pushed v* tags this new PyPI job is independent of the release job below: publish-pypi waits on build-wheels/build-plugin, while release still waits only on build-rust/build-plugin. If the wheel build, Trusted Publisher approval/OIDC exchange, or either upload fails, the workflow can still create a public GitHub Release for a version whose PyPI packages were never published; add the PyPI job to the tag-release dependency chain or otherwise sequence the Release after successful uploads.
Useful? React with 👍 / 👎.
| - Contributing: https://github.com/tachyon-beep/clarion/blob/main/CLAUDE.md | ||
| - License: https://github.com/tachyon-beep/clarion/blob/main/LICENSE | ||
| - Changelog: https://github.com/foundryside-dev/loomweave/blob/main/CHANGELOG.md | ||
| - Contributing: https://github.com/foundryside-dev/loomweave/blob/main/CLAUDE.md |
There was a problem hiding this comment.
Restore the Contributing link target
This nav entry now points the published docs site at github.com/foundryside-dev/loomweave/blob/main/CLAUDE.md, but the same rename/removal commit deletes the in-repo CLAUDE.md/AGENTS.md files and there is no replacement contributing document in the tree. The About → Contributing link on the deployed site will 404 for every visitor; point it at an existing document or remove the nav item.
Useful? React with 👍 / 👎.
| const GITIGNORE_CONTENTS: &str = "\ | ||
| # Clarion .gitignore — ADR-005 tracked-vs-excluded list. | ||
| # Tracked (committed): clarion.db, config.json, .gitignore itself. | ||
| # Loomweave .gitignore — ADR-005 tracked-vs-excluded list. | ||
| # Tracked (committed): loomweave.db, config.json, .gitignore itself. | ||
| # Excluded (ignored): WAL sidecars, shadow DB, per-run logs, tmp scratch. |
There was a problem hiding this comment.
Ignore runtime files in installed projects
Fresh projects get this .loomweave/.gitignore template from loomweave install, but it still declares loomweave.db as tracked and omits the loomweave.db, instance_id, and loomweave.lock ignore rules that this commit added to the repository's own .loomweave/.gitignore/root .gitignore for runtime artifacts. Users initializing a new repo will therefore see the generated SQLite DB and per-project runtime files as committable, unlike the dogfood repo; align the installer template with the new ignore policy.
Useful? React with 👍 / 👎.
The Clarion→Loomweave / Loom→Weft rename lengthened string literals and identifiers (`loomweave:eid:`, `loomweave_*`, `WEFT_*`), pushing several lines past the 100-col limit and changing `use` sort order. Pure rustfmt rewrap — no logic changes. (cargo fmt --check is the release `verify` gate; clippy + nextest were already green, fmt was the gap.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ca621ba934
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| pipx install \ | ||
| "https://github.com/tachyon-beep/clarion/releases/download/${TAG}/clarion-plugin-python-1.2.0.tar.gz" | ||
| "https://github.com/foundryside-dev/loomweave/releases/download/${TAG}/loomweave-plugin-python-1.2.0.tar.gz" |
There was a problem hiding this comment.
Point the home-page install link at the 1.0.0 release
The published web home page still tells users to install with TAG=v1.2.0 and a loomweave-plugin-python-1.2.0.tar.gz asset, while this recut publishes the Loomweave packages and release artifacts as 1.0.0. Users starting from the docs landing page will hit missing release assets instead of installing the first Loomweave release; update this snippet to the same v1.0.0 / 1.0.0 values used by the root README and operator guide.
Useful? React with 👍 / 👎.
| install loomweave-x86_64-unknown-linux-gnu/loomweave ~/.local/bin/ | ||
| pipx install \ | ||
| "https://github.com/tachyon-beep/clarion/releases/download/${TAG}/clarion-plugin-python-1.3.0.tar.gz" | ||
| "https://github.com/foundryside-dev/loomweave/releases/download/${TAG}/loomweave-plugin-python-1.0.0.tar.gz" |
There was a problem hiding this comment.
Use the generated sdist name in install snippets
This hard-coded GitHub Release URL uses the display project name with hyphens, but the release workflow itself avoids hard-coding the sdist because hatchling/PEP 625 filename normalization can publish the artifact as loomweave_plugin_python-1.0.0.tar.gz instead. In that normal release case, the README quick start 404s even though the tag and version are correct; update the snippet to the generated asset name or avoid a literal filename as the release notes do.
Useful? React with 👍 / 👎.
Lands the Loomweave 1.0.0 changeset and the gated PyPI publish path. Merging this puts the 1.0.0 loomweave code on
mainso av1.0.0tag can publish.What this lands (11 commits)
current_exe()plugin discovery + doctor real-discovery (the PyPI-enabling foundation).Clarion→Loomweave/Loom→Weftrename + version recut1.3.0→1.0.0, incl. the federation wire layer (/api/loom→/api/weft,X-Loom-*→X-Weft-*,clarion_entity_id→loomweave_entity_id,CLA-→LMWV-, DB magicCLRN→LMWV). Carve-outs (Filigree issue IDs,docs/archive/,.filigree.conf) left intentionally.crates/loomweave-cli/pyproject.toml(maturinbindings=bin); version-lockstep guard extended (+--self-test).release.ymlextended with gated PyPI Trusted Publishing (plugin-first).Verification
cargo build --workspace✓ ·cargo nextest run1164/1164 ✓ · clippy clean · pytest 166 ✓.current_exe()×fixture interaction — fixed by renaming the fixture[[bin]]off theloomweave-plugin-*glob.loomweave doctordiscovers the python plugin viacurrent_exe()(one-command PyPI topology works post-rename).v1.0.0(do NOT tag yet)The publish job is committed but unvalidated. Required first:
mainhas 1.0.0).loomweaveandloomweave-plugin-python: ownerfoundryside-dev, repoloomweave, workflowrelease.yml, envpypi(+ atestpypienv/publishers for the dry-run). Recommended: required reviewers on thepypienvironment.workflow_dispatchwithtarget_index=testpypi, confirmuvx --index-url …test.pypi.org… loomweave doctorresolves.v1.0.0→ CI publishes (plugin first, then loomweave).Notes: wheel matrix is reduced (Linux x86_64 manylinux_2_28 + macOS arm64 — mirrors the binary matrix, not the plan's standard-4); off-matrix platforms fall back to the cosign GitHub-Release tarballs. Until D2,
publish-pypifails the OIDC exchange — fail-safe, cannot mis-publish.🤖 Generated with Claude Code