abstractskill 0.3.2__tar.gz → 0.3.3__tar.gz

{abstractskill-0.3.2/src/abstractskill.egg-info → abstractskill-0.3.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: abstractskill
-Version: 0.3.2
+Version: 0.3.3
 Summary: Agent Skills (SKILL.md) parsing, discovery, trust gating, and demand derivation for AbstractFramework
 Author-email: Laurent-Philippe Albou <contact@abstractcore.ai>
 License-Expression: MIT
@@ -66,7 +66,7 @@ The wheel carries the library and the curated skill registry (the shelf below).
 `pip install abstractskill` installs the reviewed shelf as package data:
 
 ```
-abstractskill/registry/skills/            # 14 curated skills (one folder per SKILL.md)
+abstractskill/registry/skills/            # 15 curated skills (one folder per SKILL.md)
 abstractskill/registry/licenses/          # upstream licenses of catalog-vendored skills
 abstractskill/registry/validations.yaml   # trust records: byte pins per skill tree
 abstractskill/registry/advisories.yaml    # do-not-use advisories (empty at v1, by design)

{abstractskill-0.3.2 → abstractskill-0.3.3}/README.md

@@ -33,7 +33,7 @@ The wheel carries the library and the curated skill registry (the shelf below).
 `pip install abstractskill` installs the reviewed shelf as package data:
 
 ```
-abstractskill/registry/skills/            # 14 curated skills (one folder per SKILL.md)
+abstractskill/registry/skills/            # 15 curated skills (one folder per SKILL.md)
 abstractskill/registry/licenses/          # upstream licenses of catalog-vendored skills
 abstractskill/registry/validations.yaml   # trust records: byte pins per skill tree
 abstractskill/registry/advisories.yaml    # do-not-use advisories (empty at v1, by design)

{abstractskill-0.3.2 → abstractskill-0.3.3}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "abstractskill"
-version = "0.3.2"
+version = "0.3.3"
 description = "Agent Skills (SKILL.md) parsing, discovery, trust gating, and demand derivation for AbstractFramework"
 readme = "README.md"
 requires-python = ">=3.10"

{abstractskill-0.3.2 → abstractskill-0.3.3}/src/abstractskill/__init__.py

@@ -140,4 +140,4 @@ __all__ = [
     "validate_skill_name",
 ]
 
-__version__ = "0.3.2"
+__version__ = "0.3.3"

{abstractskill-0.3.2 → abstractskill-0.3.3}/src/abstractskill/registry/catalog.yaml

@@ -16,7 +16,7 @@
 # four yaml files shipped in the abstractskill wheel). Bump it whenever any
 # of that content changes; seed_registry() records it in <dest>/.seeded.json
 # and tests/test_bundled.py pins it to a content digest.
-version: "2026.10.21"
+version: "2026.10.27"
 
 skills:
 

abstractskill-0.3.3/src/abstractskill/registry/skills/abstract-release/SKILL.md

@@ -0,0 +1,209 @@
+---
+name: abstract-release
+description: Plan and run an AbstractFramework release wave across its packages in dependency order. Covers which packages changed, the release order, the per-package mechanics (tag push or workflow_dispatch, the PyPI/npm/crates.io GitHub environments), the gates (adversarial review before merge, real-weights or real-gateway end-to-end checks, merge only on all-green, registry visibility, dependency-floor propagation with the install-profile pin tests), and the final report. Use when releasing one or more AbstractFramework packages, raising inter-package floors, publishing the root `abstractframework` profile, or auditing whether a release wave is complete. For a single package with no dependents, the package-level `release` skill is enough.
+---
+
+# Abstract Release
+
+AbstractFramework is 34 packages in 22 repositories on 2026-10-27 (Python on PyPI, npm packages
+and apps, Rust crates on crates.io; `./scripts/deps.sh` in the workspace lists them). A release
+wave publishes the changed ones from the bottom of the dependency graph upward, so every package
+a parent depends on is already published, green, and visible on its registry before the parent
+raises its floor and publishes.
+
+This skill orchestrates the wave. Inside each package, use the `release` skill (version, changelog,
+tag, publish), `coredoc` (README, docs, llms files, version source), `backlog` (the work item and
+its evidence) and `adr` (durable rules). This skill adds what only shows up across packages: the
+order, the gates between packages, floor propagation, and the root profile.
+
+## Before you start
+
+- Default to a read-only plan. Commits, pushes, tags, workflow dispatches, publishes, CI reruns and
+  skipped gates need the operator's explicit approval (see the approval packet in
+  `references/release-process.md`).
+- Set the skill directory once; the scripts run from any working directory:
+
+```bash
+SKILL_DIR=~/.claude/skills/abstract-release        # or wherever this skill is installed
+AF_ROOT=/path/to/abstractframework                 # the workspace root (holds scripts/lib/packages.txt)
+git -C "$AF_ROOT/<repo>" fetch --tags      # per repository: the planner reads local release tags
+python3 "$SKILL_DIR/scripts/abstract_release_plan.py" "$AF_ROOT" --registry
+python3 "$SKILL_DIR/scripts/abstract_release_plan.py" "$AF_ROOT" --registry --json -o "$AF_ROOT/untracked/release-plan.json"
+```
+
+  Without a path, the planner finds the workspace by walking up from the current directory
+  (or reads `ABSTRACTFRAMEWORK_ROOT`). A package is in the wave when it has uncommitted changes,
+  commits since its last release tag, a version with no tag, or (with `--registry`) a version not
+  on its registry; packages downstream of one are added for a floor review only.
+- Read `references/package-inventory.md` for the tiers and each package's version source,
+  release trigger and registry environment. Read `references/release-process.md` before the first
+  irreversible step.
+- Operator checkouts can hold uncommitted work that is not yours. Never stage it, never rebase a
+  diverged branch for the operator. When you need a clean tree, use a worktree in a scratch
+  directory.
+
+## The order
+
+Release by published dependency floors, not by what happens to pass locally:
+
+1. Independent lower packages: `abstractvoice`, `abstractvision`, `abstractmusic` (and the other
+   tier-0 media plugins), `abstractskill`, and the AbstractUIC npm packages (`ui-kit`,
+   `app-server`, `monitor-*`, `panel-chat`).
+2. `abstractsemantics` and `abstractmemory` (AbstractMemory owns the memory graph).
+3. `abstractcore`.
+4. `abstractruntime`.
+5. `abstractagent`.
+6. `abstractgateway`.
+7. Apps on the gateway: `abstractassistant`, `abstractcode`, `abstractobserver`, `abstractentity`,
+   `abstractflow`, `abstractcontinuum`, `abstractnote` (Python on the gateway and AbstractMemory,
+   plus its web app).
+8. Root `abstractframework`: pins, `RELEASE_VERSIONS`, install manifest, installers, install docs.
+
+The planner refines this from the real manifests: it skips packages with nothing to release and
+adds every package downstream of a changed package for a floor review. `scripts/lib/packages.txt`
+in the workspace is the inventory the workspace scripts use; the planner reports any package it
+finds on disk that the inventory is missing.
+
+## The per-package loop
+
+Repeat for each package in the plan's `release_wave`, lowest order first.
+
+1. **Work item.** Every change has a `backlog` item in its own package; close it with evidence.
+   A rule that should outlive the task (for example "no direct lower-level imports; a missing
+   capability is surfaced by the runtime") becomes an ADR.
+2. **Version and docs.** Bump the package's version source (named per package in
+   `references/package-inventory.md`; some packages keep it in two places that must agree). Fold
+   `Unreleased` into one dated `CHANGELOG.md` section for the version. Run `coredoc`'s release
+   checklist: version source, README badges and install snippets, package metadata, llms files
+   regenerated with the package's generator and committed, backlog/ADR trace.
+3. **Local proof.** Run the package tests. For anything that touches an engine, run a real-weights
+   end-to-end check on the machine, not a mock. For gateway routes, go through a scratch gateway
+   over HTTP (recipe in `references/release-process.md`). A local failure can be the stale venv,
+   not the code: CI installs from the published pins, so decide per failure whether it is a code
+   bug or the environment (keys in the shell, CLIs on PATH, missing extras, older siblings).
+4. **Adversarial review before merge.** A read-only reviewer that did not write the diff reviews
+   it. Fix the confirmed findings, re-verify, and record what was found.
+5. **Pull request, merge only on all-green.**
+
+```bash
+gh pr create --base main --head <branch> --title "<package> X.Y.Z: <summary>" --body-file <notes.md>
+gh pr checks <N> --watch
+gh pr checks <N> | awk -F'\t' '{print $2}' | sort -u     # must print exactly: pass
+gh pr merge <N> --merge                                  # alone, never chained after other commands
+gh pr view <N> --json state,mergeCommit                  # confirm MERGED before tagging
+```
+
+6. **Publish.** Read the package's row in `references/package-inventory.md` (trigger, dispatch
+   inputs, environment policy) first. Then:
+   - Confirm the publishing environment admits the ref you will publish from, or the publish job
+     is refused after the build passed (a 404 means no policy: any ref may deploy):
+
+```bash
+gh api repos/lpalbou/<Repo>/environments/<pypi|npm|crates-io>/deployment-branch-policies \
+  --jq '.branch_policies[]|"\(.type):\(.name)"'
+```
+
+   - Confirm you publish the merged commit:
+     `git switch main && git pull --ff-only`, then `git rev-parse HEAD` must equal the PR's
+     `mergeCommit.oid`.
+   - Tag push (most packages; AbstractUIC tags its root `package.json` version, AbstractCode's
+     web app tags `web-vX.Y.Z`):
+
+```bash
+git tag -a vX.Y.Z -m "<package> X.Y.Z" && git push origin vX.Y.Z
+```
+
+   - Or `workflow_dispatch` from main, with the inputs that workflow declares (the run builds,
+     publishes and creates the tag; required where the environment admits only `main`, as for
+     AbstractAssistant):
+
+```bash
+gh workflow run release.yml --ref main -f version=X.Y.Z                 # most Python packages
+gh workflow run release.yml --ref main -f version=X.Y.Z -f publish=true \
+  -f publish_confirmation=publish-<package>-X.Y.Z                       # AbstractRuntime, AbstractMusic
+```
+
+   - Follow the run: `gh run list --workflow release.yml --branch vX.Y.Z -L 1` for a tag push
+     (`--event workflow_dispatch` for a dispatch), then `gh run watch <run-id> --exit-status`.
+7. **Visibility gate.** The registry index lags the upload. Do not raise a floor upstream until
+   the version resolves:
+
+```bash
+python3 "$SKILL_DIR/scripts/pypi_visibility_gate.py" --wait 900 abstractvoice==X.Y.Z
+python3 "$SKILL_DIR/scripts/pypi_visibility_gate.py" --wait 900 npm:@abstractframework/ui-kit==X.Y.Z
+python3 "$SKILL_DIR/scripts/pypi_visibility_gate.py" --wait 900 crates:abstractgateway-console==X.Y.Z
+```
+
+8. **Floor propagation.** Raise the floor in each direct dependent the plan lists under
+   `dependency_floor_reviews`. Update the tests that pin floors literally in the same change
+   (for example AbstractGateway's `tests/test_gateway_install_profiles.py` and
+   `live_deltas.ABSTRACTRUNTIME_FLOOR`), respect the cross-package floor rules in
+   `references/package-inventory.md`, and refresh npm lockfiles after an AbstractUIC publish.
+   Rerun the planner and continue with the updated wave.
+
+## Gates (never skipped without the operator's approval)
+
+1. Adversarial review of every diff before merge.
+2. Real-weights (engines) or real-gateway (routes) end-to-end proof on the machine.
+3. Merge only when every check is `pass`; check the PR state after merging.
+4. A parent is released only after each lower version is visible on its registry and the lower
+   package's release run is green.
+5. Every dependent's floor or exact pin is raised or explicitly confirmed, with its pin tests.
+6. One dated changelog section per released version; llms files regenerated; backlog item closed
+   with evidence; durable rules recorded as ADRs.
+7. No publish from a checkout with uncommitted release-scope changes.
+8. Root `abstractframework` last, and only when its pins, `RELEASE_VERSIONS`, install manifest,
+   installers and install docs match the released matrix. If the wave stops earlier, either
+   release the root profile in the same approved wave or file a backlog item and say plainly that
+   `pip install abstractframework[...]` still resolves the older matrix.
+
+Stop and report on: an ambiguous version source, a duplicate target version, an unclear publish
+destination, a red or unknown check, a version not visible on its registry, or a floor that still
+points below a just-released version.
+
+## Final report
+
+End the wave with this report (one row per package touched, including the ones you decided not
+to release):
+
+```markdown
+# AbstractFramework release wave <date>
+
+| Package | Released | Registry | Release run | Floors raised in dependents |
+|---|---|---|---|---|
+| abstractvoice | 0.19.1 (from 0.18.2) | PyPI, visible | <run URL>, green | abstractcore >=0.19.1 |
+| ... | not released: <reason> | | | |
+
+## New capabilities (per package, user-facing)
+- abstractvoice 0.19.1: ...
+
+## Gates
+- Adversarial reviews: <package: findings fixed / none>
+- End-to-end proofs: <package: what ran, on which weights or gateway>
+- Root profile: released X.Y.Z | not released, backlog <id>, users of `abstractframework[...]` still get <old matrix>
+
+## Remaining work and improvements
+- <package>: <follow-up>, backlog <id>
+- Process: <what slowed the wave, the fix proposed>
+```
+
+## Scripts
+
+- `scripts/abstract_release_plan.py [ROOT] [--registry] [--json] [-o FILE]`: read-only
+  inventory, dependency order, release signals per package, release wave, floor reviews, root pin
+  drift (pyproject pins and `RELEASE_VERSIONS` / `NPM_RELEASE_VERSIONS` / `CRATE_RELEASE_VERSIONS`),
+  changes outside any package, and packages missing from `scripts/lib/packages.txt`. Needs
+  Python 3.11+ (or `tomli` installed).
+- `scripts/pypi_visibility_gate.py SPEC... [--from-plan FILE] [--wait SECONDS]`: checks that each
+  `name==version` (PyPI), `npm:@scope/name==version` or `crates:name==version` is installable from
+  its registry; `--from-plan` checks the plan's changed packages; with `--wait` it polls until
+  visible or the deadline passes. Exit code 0 only when all are visible. Python 3.9+.
+
+## References
+
+- `references/release-process.md`: the full process: order, per-package loop, gates in detail,
+  the scratch-gateway recipe, changelog/llms/backlog/ADR duties, approval packet, stop conditions,
+  partial releases, and the pitfalls seen in practice.
+- `references/package-inventory.md`: the tiers, and per package its version source, release
+  trigger, registry environment, llms generator, and package-specific rules.
+- `references/package-discovery.md`: how the planner discovers packages and reads its output.

abstractskill-0.3.3/src/abstractskill/registry/skills/abstract-release/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Abstract Release"
+  short_description: "Release AbstractFramework packages in dependency order, with gates."
+  default_prompt: "Use $abstract-release to plan an AbstractFramework release wave from the changed packages upward, run each package through review, end-to-end proof, all-green merge, publish and registry visibility, propagate dependency floors, and end with the wave report."

abstractskill-0.3.3/src/abstractskill/registry/skills/abstract-release/references/package-discovery.md

@@ -0,0 +1,74 @@
+# Package Discovery
+
+`scripts/abstract_release_plan.py` builds a deterministic, read-only picture of the workspace. Run
+it before the wave, after every release, and after every floor bump.
+
+```bash
+python3 "$SKILL_DIR/scripts/abstract_release_plan.py" "$AF_ROOT" --registry
+python3 "$SKILL_DIR/scripts/abstract_release_plan.py" "$AF_ROOT" --registry --json -o "$AF_ROOT/untracked/release-plan.json"
+```
+
+Without a path it uses `ABSTRACTFRAMEWORK_ROOT`, else the nearest ancestor of the current directory
+that holds `scripts/lib/packages.txt`, and stops with an error when there is none (it never walks
+an arbitrary directory unless you pass it explicitly). It needs Python 3.11+ (tomllib) or the
+`tomli` backport.
+
+## Release signals
+
+A package is **changed** (a release candidate) when any of these holds:
+
+- uncommitted changes in its directory (`git status`);
+- commits touching its directory since its last release tag (`git describe --match 'v*'`; a
+  package in a sub-directory with its own tag family, such as AbstractCode's `web-v*`, uses it).
+  Tags are read locally: run `git fetch --tags` in each repository first, or a release a workflow
+  tagged remotely shows as untagged;
+- for a package at its repository root, no local tag `v<version>`;
+- with `--registry`, its local version is missing from PyPI, npm or crates.io (a 404; a network
+  error leaves it unknown, never "unpublished").
+
+Every package downstream of a changed package joins the wave as "floor review only".
+
+## How it finds packages
+
+- **With the inventory** (`scripts/lib/packages.txt`, the list the workspace scripts read): one
+  package per row, read from `<repo>/<path>` (`pyproject.toml`, `package.json` or `Cargo.toml`).
+  Scratch copies elsewhere in the workspace (worktrees and audits under `untracked/`, release
+  checkouts) are never mistaken for the real package.
+- **Without the inventory**: a filesystem walk that skips `untracked/`, virtualenvs,
+  `node_modules`, `site-packages`, build output and `*-backup` / `*-gh-pages` folders, plus the
+  local experiment projects (`abstractaudio`, `abstractsound`, `abstractvideo`,
+  `abstractcognition`, `abstractgeometry`, `abstractspatial`). Two packages with the same name stop
+  the run with both paths listed.
+
+The root meta-package's `NPM_RELEASE_VERSIONS` and `CRATE_RELEASE_VERSIONS` pins count as
+dependency edges, so an app or crate release reaches the root's floor review.
+
+For each package it reads the version (static, or the setuptools `attr` the pyproject points to),
+the internal dependencies (Python `dependencies` and extras, npm dependency groups, Cargo
+`[dependencies]`), and `git status` for the package directory. Changes inside a nested package's
+directory belong to that package (AbstractUIC's packages, the gateway's `console-tui` crate,
+AbstractNote's `web` app, the sibling repositories under the root).
+
+Vite source aliases into the AbstractUIC checkout are not in any manifest. With the inventory they
+come from its `alias` edges (verified by `./scripts/deps.sh check`); without it, from a text scan
+of the package sources for sibling npm package names, which can over-report.
+
+## Output
+
+The Markdown is for reading; the JSON is for follow-up checks and release logs.
+
+- `ordered_packages`: every package in dependency order (ties broken by the ADR-0034 tier rank).
+- `release_wave`: changed packages (`changed: true`, with the reasons) plus every package
+  downstream of one (`floor review only`).
+- `dependency_floor_reviews`: each internal requirement inside the wave, with the declared range
+  and the lower package's local version: raise or confirm it after the lower publish is visible.
+- `profile_pin_reviews`: the root pins (`pyproject.toml` exact pins, `RELEASE_VERSIONS`,
+  `NPM_RELEASE_VERSIONS`, `CRATE_RELEASE_VERSIONS`) against local versions; `drift` means the root
+  profile would not deliver the local version.
+- `changes_outside_packages`: uncommitted changes in a package repository that no package
+  directory owns (for example AbstractUIC's root `package.json`, which names its release tag, and
+  its lockfile). Assign them to a release by hand.
+- `inventory_gaps`: packages the workspace scripts would miss: `repo_not_in_inventory` (a sibling
+  AbstractFramework repository with no row), `package_not_in_inventory` (a public manifest tracked
+  in a listed repository, outside tests, fixtures, examples and docs), `not_cloned`,
+  `name_mismatch`.

abstractskill-0.3.3/src/abstractskill/registry/skills/abstract-release/references/package-inventory.md

@@ -0,0 +1,131 @@
+# Package Inventory
+
+What exists, in which order it releases, and how each package releases. The workspace's
+`scripts/lib/packages.txt` is the machine-readable inventory (`./scripts/deps.sh` prints the tiers,
+`./scripts/deps.sh check` verifies them against the real manifests, `./scripts/deps.sh rdeps <id>`
+lists what must follow a bump). This page adds the release mechanics. Facts were read from the
+repositories and their GitHub settings on 2026-10-27; re-check a row before relying on it for an
+irreversible step.
+
+## Tiers
+
+Tier = dependency depth from `packages.txt`. A package releases only after every package it
+depends on is published and visible.
+
+| Tier | Python (PyPI) | npm | Rust (crates.io) |
+|---|---|---|---|
+| 0 | abstractskill, abstractsemantics, AbstractMemory, abstractvision, abstractvoice, abstractmusic, abstractcamera | ui-kit, app-server, monitor-flow, monitor-gpu, monitor-memory, monitor-active-memory | abstracttui |
+| 1 | abstract3d (needs abstractvision) | panel-chat (peer of ui-kit) | abstracttui-graph, abstractcore-console, abstractcode (CLI) |
+| 2 | abstractcore (needs voice, vision, music, 3d) | flow, observer, continuum, entity, code (web), note (web) | abstracttui-mermaid, abstractgateway-console |
+| 3 | AbstractRuntime (needs core, memory, semantics) | | |
+| 4 | abstractagent, abstractassistant | | |
+| 5 | abstractgateway | | |
+| 6 | abstractnote, abstractframework (root meta-package) | | |
+
+Roles worth knowing when you order a wave:
+
+- **AbstractMemory** owns the memory graph (temporal assertions, the graph store and its
+  operations). AbstractRuntime, AbstractGateway and AbstractNote build on it, so a memory change
+  can ripple to all three.
+- **AbstractCore** depends on the media plugins (voice, vision, music, 3d). Avoid a Core release in
+  the middle of a wave unless the change needs it; its floor propagation is the slow path.
+- **AbstractGateway** is the one HTTP door; the apps are thin clients of it.
+- **AbstractNote** is a notes app on the gateway: a Python package (`abstractnote`, depends on
+  AbstractMemory, AbstractSemantics, AbstractRuntime and AbstractCore; reaches the gateway through
+  its `gateway` extra) plus a web app (`@abstractframework/note`). The gateway imports
+  `abstractnote` lazily as an optional seam, so it is not a gateway dependency; AbstractNote
+  releases after the gateway it needs.
+- **abstractframework** (root) pins exact versions of the released matrix and releases last.
+
+Not released with the framework: the local test projects `abstractaudio`, `abstractsound`,
+`abstractvideo`, `abstractcognition`, `abstractgeometry`, `abstractspatial` (the planner skips
+them).
+
+## Release mechanics per package
+
+Trigger: **tag** = push `vX.Y.Z` (`release.yml` on tag push); **dispatch** = `gh workflow run
+release.yml --ref main ...` with the inputs named in the row. Most Python workflows accept both:
+dispatched with `-f version=X.Y.Z`, they build, publish and create the tag themselves (an
+`ensure-tag` job), which also satisfies an environment that admits only `main`. Dispatch inputs
+differ per workflow and gh refuses unknown inputs ("Unexpected inputs"), so read the row, and read
+the publish jobs' `if:` conditions before dispatching a workflow the table does not cover.
+Environment policy = the deployment branch/tag policy of the publishing environment: a tag-push
+release needs a tag rule there.
+
+| Dispatch inputs | Packages |
+|---|---|
+| `-f version=X.Y.Z` | abstractvoice, abstractvision, abstractcamera, abstractskill, abstractsemantics, AbstractMemory, abstractcore, abstractagent, abstractassistant, abstractgateway, abstractflow |
+| `-f version=X.Y.Z -f publish=true -f publish_confirmation=publish-<package>-X.Y.Z` | AbstractRuntime, abstractmusic |
+| `-f version=X.Y.Z` (`-f dry_run=true` rehearses) | abstractnote |
+| `-f target=web` or `-f target=cli` (default `all`) | AbstractCode |
+| `-f publish=true` | abstracttui (and its extension crates) |
+| none | abstractuic, abstractobserver, abstractentity, abstractcontinuum, root abstractframework (check the workflow's publish conditions first) |
+| none, and dispatch publishes nothing | abstract3d: publishes only from a `v*` tag |
+
+### Python
+
+| Package | Repo | Version source | Trigger | `pypi` env policy | llms generator | Notes |
+|---|---|---|---|---|---|---|
+| abstractvoice | lpalbou/AbstractVoice | `abstractvoice/_version.py` (single source; pyproject reads it) | tag | main, tag `v*.*.*` | none (edit by hand) | PR CI: tests 3.9-3.12, Qwen3-TTS/ASR transformers floor and latest, build, docs (10 checks). release.yml publishes to PyPI with trusted publishing, creates the GitHub release, deploys docs. |
+| abstractvision | lpalbou/AbstractVision | `src/abstractvision/__init__.py` | tag | no restriction | `scripts/generate_llms_full.py` | |
+| abstractmusic | lpalbou/AbstractMusic | `src/abstractmusic/_version.py` | tag or dispatch (`-f publish=true -f publish_confirmation=publish-abstractmusic-X.Y.Z`) | main, tag `v*.*.*` | none | |
+| abstractcamera | lpalbou/AbstractCamera | `src/abstractcamera/__init__.py` | tag | main, tag `v*` | `scripts/generate_llms_full.py` | Ships a package agent skill (`skills/camera-piloting/`). |
+| abstract3d | lpalbou/Abstract3D | `pyproject.toml` and `src/abstract3d/__init__.py` | tag `v*` only (the publish jobs run only on `refs/tags/v*`; a dispatch publishes nothing) | main, tag `v*` | none | AbstractCore depends on it: release before Core. |
+| abstractskill | lpalbou/AbstractSkill | `pyproject.toml` and `src/abstractskill/__init__.py` | tag | main, tag `v*` | `scripts/generate_llms_full.py` | Shelf changes: `scripts/refresh_shelf.py`, bump `catalog.yaml` `version`, update the pins in `tests/test_bundled.py` and `tests/test_shelf.py`. |
+| abstractsemantics | lpalbou/AbstractSemantics | `pyproject.toml` | tag | main, tag `v*.*.*` | `scripts/generate_llms_full.py` | |
+| AbstractMemory | lpalbou/AbstractMemory | `pyproject.toml` | tag | main, tag `v*.*.*` | none | Memory graph owner. |
+| abstractcore | lpalbou/AbstractCore | `abstractcore/utils/version.py` | tag | main, tag `v*.*.*` | `scripts/update_llms.py` | Also publishes the `abstractcore-console` crate and GHCR images. Ships `skills/abstractcore/`. |
+| AbstractRuntime | lpalbou/AbstractRuntime | `pyproject.toml` | dispatch: `gh workflow run release.yml --ref main -f version=X.Y.Z -f publish=true -f publish_confirmation=publish-abstractruntime-X.Y.Z` (the run creates the tag); a tag push also works | main, tag `v*.*.*` (tag rule added 2026-10-27) | `scripts/generate_llms_full.py` (commit the output) | PR CI: 7 checks. |
+| abstractagent | lpalbou/AbstractAgent | `pyproject.toml` | tag | main, tag `v*.*.*` | none | |
+| abstractassistant | lpalbou/AbstractAssistant | `pyproject.toml` and `abstractassistant/_version.py` (a test keeps them equal) | dispatch: `gh workflow run release.yml --ref main -f version=X.Y.Z` (creates the tag) | **main only**: a tag-push run is refused at the publish job; dispatch from main, or ask the operator to add a tag rule | `scripts/update_llms_full.py` | Desktop app plus iPhone (`phone/iphone`, xcodegen, `iphone.yml`) and watch (`watch.yml`) workflows. |
+| abstractgateway | lpalbou/AbstractGateway | `pyproject.toml` and `src/abstractgateway/__init__.py` | tag | main, tag `v*` | `scripts/generate-llms-full.py` | release.yml: tests 3.10-3.13, build, docs, the `abstractgateway-console` crate to crates.io when `console-tui/Cargo.toml` has a new version, GHCR images. See the floor rules below. |
+| abstractnote | lpalbou/AbstractNote | `pyproject.toml`, `src/abstractnote/__init__.py` and `web/package.json` (the release validates the tag against pyproject and web) | tag, or dispatch with `-f version=X.Y.Z` (`-f dry_run=true` rehearses) | no restriction (`npm` env: main, tag `v*`) | `scripts/build_llms_full.py` | One release publishes the Python package and the web app. Needs the gateway release that carries the AbstractNote seam (`abstractgateway>=0.15.11`). |
+| abstractframework | lpalbou/AbstractFramework | `pyproject.toml` and `abstractframework/__init__.py` (`__version__`, `RELEASE_VERSIONS`, `NPM_RELEASE_VERSIONS`, `CRATE_RELEASE_VERSIONS`) | tag | main, tag `v*` | `scripts/gen_llms_full.py` (`--check`) | Last. Also `docs/installers/install-manifest.json`, `scripts/install.sh`, `scripts/install.ps1`, install docs; `scripts/tests/test_inventory.sh` checks they agree. |
+
+### npm
+
+| Package | Repo / path | Version source | Trigger | `npm` env policy | Notes |
+|---|---|---|---|---|---|
+| ui-kit, app-server, monitor-flow, monitor-gpu, monitor-memory, monitor-active-memory, panel-chat | lpalbou/AbstractUIC, `<pkg>/package.json` | each package's `package.json`; the root `package.json` version names the release tag; root `package-lock.json` entries must match (`npm install --package-lock-only`) | PR, merge on green (one job "Test, build, and pack"), then tag `vX.Y.Z` = root version | main, tag `v*` | release.yml publishes each changed package with `npm publish --provenance`. Verify with `npm view @abstractframework/ui-kit version`. llms: `scripts/generate-llms-full.py`. |
+| @abstractframework/flow | lpalbou/AbstractFlow | `package.json` | tag | main, tag `v*` | `npm run check:lock` fails until the pinned ui-kit is on npm; after it is, `npm install` and commit the lockfile. |
+| @abstractframework/observer | lpalbou/AbstractObserver | `package.json` | tag | main, tag `v*` | same lockfile rule |
+| @abstractframework/entity | lpalbou/AbstractEntity | `package.json` | tag | no restriction | same lockfile rule |
+| @abstractframework/continuum | lpalbou/AbstractContinuum | `package.json` | tag | no restriction | same lockfile rule |
+| @abstractframework/code | lpalbou/AbstractCode, `web/` (`npm --prefix web`) | `web/package.json` (versioned independently of the crate) | tag `web-vX.Y.Z` (a `vX.Y.Z` tag publishes only the crate), or dispatch `-f target=web` | main, tag `v*`, tag `web-v*` | same lockfile rule; the repository also holds the `abstractcode` crate |
+| @abstractframework/note | lpalbou/AbstractNote, `web/` | `web/package.json` (equal to the Python version) | with abstractnote | main, tag `v*` | |
+
+### Rust
+
+| Crate | Repo / path | Trigger | `crates-io` env policy |
+|---|---|---|---|
+| abstracttui | lpalbou/AbstractTUI | tag `v*`, or dispatch `-f publish=true` (without it the run only verifies) | no restriction |
+| abstracttui-graph, abstracttui-mermaid | lpalbou/AbstractTUI, `extensions/graph`, `extensions/mermaid` | with abstracttui: the `publish-family` job publishes graph, then mermaid (mermaid depends on graph) | no restriction |
+| abstractcore-console | lpalbou/AbstractCore, `console-tui/` | with AbstractCore | no restriction |
+| abstractgateway-console | lpalbou/AbstractGateway, `console-tui/` | with AbstractGateway, when `console-tui/Cargo.toml` has a new version | no restriction |
+| abstractcode | lpalbou/AbstractCode, `tui/` (versioned independently of the web app) | tag `vX.Y.Z` only: its `crates-io` environment admits only `v*` tags, so a dispatch with `target=cli` or `all` is refused at `publish-crate` | tag `v*` |
+
+Check a policy before a tag push:
+
+```bash
+gh api repos/lpalbou/<Repo>/environments/<pypi|npm|crates-io>/deployment-branch-policies \
+  --jq '.branch_policies[]|"\(.type):\(.name)"'
+```
+
+A 404 means the environment has no custom policy (any ref may deploy).
+
+## Cross-package floor rules
+
+- **Gateway install profiles.** `abstractgateway/tests/test_gateway_install_profiles.py` pins the
+  gateway's dependency floors literally. Update it in the same change as any floor.
+- **Gateway AbstractVoice floor ≤ Core's.** The same test requires the gateway's `abstractvoice`
+  floor to be at most AbstractCore's own `abstractvoice` floor, so the gateway never pins a newer
+  AbstractVoice than Core declares. Release Core with the new floor first, or document "install
+  the latest AbstractVoice" instead of pinning it.
+- **Runtime floor constant.** `abstractgateway.live_deltas.ABSTRACTRUNTIME_FLOOR` must equal the
+  gateway's pyproject `abstractruntime` floor (the startup "runtime too old" check reads it).
+- **AbstractNote gateway extra.** `abstractnote[gateway]` requires the first gateway release with
+  the AbstractNote seam; raise it when the seam changes.
+- **Root pins.** The root pins exact versions (`==`); every release that should reach
+  `pip install abstractframework[...]` needs a root release.
+- **npm apps and AbstractUIC.** Apps pin AbstractUIC packages with a caret range; raise the range
+  and refresh the lockfile after the AbstractUIC publish is visible.