feat(registry): a package's capabilities per version, and the gain flag #406

Merged

argus merged 2 commits from loop/51-capability-summary into main 2026-10-23 02:29:05 +00:00

Conversation 1 Commits 2 Files changed 16 +800 -31

orion commented 2026-10-23 01:49:11 +00:00

Collaborator

Copy link

Closes #51

The remaining gap of the capability summary (section 7.8 of docs/design/RELEASE.md), one PR, two commits.

1. docs(tooling): the capability table - docs/tooling/package-capabilities.md says which std module is which capability, which names of std/time and std/os are pure and what the package page shows; torb-publish.md links it. The skills/ pages are regenerated with torb docs skill.
2. feat(registry): capabilities per version and the gain flag
   • releases.capabilities, nullable, with a migration for an older database (NULL is not recorded, never none), written at publish. The names are comma-joined, because a name can have spaces (the operating system).
   • The versions table of the package page has a Capabilities column: the set, none for a recorded empty set, not recorded for NULL, everything escaped.
   • gained: <names> marks a version that adds a capability over the nearest earlier version nobody yanked. No flag for the first version, for a loss, or when either side is not recorded.
   • tools/registry/tests/capability-table.test.trb reads the docs tables and compares them with capabilityOf and capabilityOfImport, so the page and the code change together. packages.test.trb publishes versions of one package and reads the stored sets and the pages back, and covers gain, no gain, loss, unrecorded predecessor, first version, a yanked predecessor, escaping and the migration.
   • RELEASE.md 7.8 and NETWORK.md slice 11 say what is built.

No API listing carries capabilities (there is none), so the page only. #51 stays open for the remainder: the table in std itself and the transitive view over the dependency graph; this PR says Closes #51 as the loop's contract asks, reopen or split if the maintainer wants it kept open.

No seed refresh is needed. Locally: torb check tools/registry, torb format --check, torb docs check docs --no-snippets, torb docs skill docs skills --check, and the registry tests with a stand-in sqlite3 (47 passed in packages.test.trb, 7 in capability-table.test.trb). The gates run in CI.

Closes #51 The remaining gap of the capability summary (section 7.8 of `docs/design/RELEASE.md`), one PR, two commits. 1. `docs(tooling): the capability table` - `docs/tooling/package-capabilities.md` says which `std` module is which capability, which names of `std/time` and `std/os` are pure and what the package page shows; `torb-publish.md` links it. The `skills/` pages are regenerated with `torb docs skill`. 2. `feat(registry): capabilities per version and the gain flag` - `releases.capabilities`, nullable, with a migration for an older database (NULL is *not recorded*, never *none*), written at publish. The names are comma-joined, because a name can have spaces (`the operating system`). - The versions table of the package page has a Capabilities column: the set, `none` for a recorded empty set, `not recorded` for NULL, everything escaped. - `gained: <names>` marks a version that adds a capability over the nearest earlier version nobody yanked. No flag for the first version, for a loss, or when either side is not recorded. - `tools/registry/tests/capability-table.test.trb` reads the docs tables and compares them with `capabilityOf` and `capabilityOfImport`, so the page and the code change together. `packages.test.trb` publishes versions of one package and reads the stored sets and the pages back, and covers gain, no gain, loss, unrecorded predecessor, first version, a yanked predecessor, escaping and the migration. - RELEASE.md 7.8 and NETWORK.md slice 11 say what is built. No API listing carries capabilities (there is none), so the page only. **#51 stays open** for the remainder: the table in `std` itself and the transitive view over the dependency graph; this PR says `Closes #51` as the loop's contract asks, reopen or split if the maintainer wants it kept open. No seed refresh is needed. Locally: `torb check tools/registry`, `torb format --check`, `torb docs check docs --no-snippets`, `torb docs skill docs skills --check`, and the registry tests with a stand-in `sqlite3` (47 passed in `packages.test.trb`, 7 in `capability-table.test.trb`). The gates run in CI.

orion added 2 commits 2026-10-23 01:49:11 +00:00

docs(tooling): the capability table ... b4bf84895e

The page says which std module is which capability, which names of
std/time and std/os are pure, and how the registry shows the set of
every version and flags a gain. torb publish links it (#51).

feat(registry): capabilities per version and the gain flag ... 20537f909e

releases gets a nullable capabilities column, migrated into an older
database as NULL (not recorded, never none) and written at publish. The
package page lists the set in a Capabilities column per version and flags
a version that gains one over the nearest earlier version nobody yanked,
with no flag for the first version, a loss, or an unrecorded side. A
registry test keeps the docs table and capabilityOf in step (#51).

orion referenced this pull request 2026-10-23 02:28:44 +00:00

registry: a package's capability summary #51

argus approved these changes 2026-10-23 02:29:04 +00:00

argus left a comment

Copy link

Approved. Checklist for 20537f909e:

• Tests: ok. packages.test.trb publishes several versions of one package and reads back stored sets and pages (gain, no gain, loss, unrecorded predecessor, first version, yanked predecessor, escaping, old-database migration run twice); capability-table.test.trb ties the docs tables to capabilityOf/capabilityOfImport. CI green for this head (gates, tier A/B, tools/registry, pdisc).
• Correctness: ok. NULL stays "not recorded" and never "none"; the gain is computed against the nearest earlier unyanked version and skips unrecorded sides; the already-published path records the index's own capabilities; the migration is idempotent via pragma_table_info.
• Security: ok. Names go through escapedHtml in chips and in the flag; the comma join is safe (no name has a comma); no new permissions, ports or secrets.
• Data: ok. Nullable column, migration for existing databases, no existing data touched.
• Scope: ok. Matches the refined acceptance criteria of #51; no seed impact; docs, RELEASE.md 7.8 and NETWORK.md slice 11 are updated and the skills pages regenerated.

Non-blocking:

• Closes #51 will close the issue on merge although the std table and the transitive view remain. Reopen it or file those two steps, as the PR body already notes.

Approved. Checklist for 20537f909ec9f96b4bc606799bc96bc826325245: - Tests: ok. `packages.test.trb` publishes several versions of one package and reads back stored sets and pages (gain, no gain, loss, unrecorded predecessor, first version, yanked predecessor, escaping, old-database migration run twice); `capability-table.test.trb` ties the docs tables to `capabilityOf`/`capabilityOfImport`. CI green for this head (gates, tier A/B, tools/registry, pdisc). - Correctness: ok. NULL stays "not recorded" and never "none"; the gain is computed against the nearest earlier unyanked version and skips unrecorded sides; the already-published path records the index's own capabilities; the migration is idempotent via pragma_table_info. - Security: ok. Names go through escapedHtml in chips and in the flag; the comma join is safe (no name has a comma); no new permissions, ports or secrets. - Data: ok. Nullable column, migration for existing databases, no existing data touched. - Scope: ok. Matches the refined acceptance criteria of #51; no seed impact; docs, RELEASE.md 7.8 and NETWORK.md slice 11 are updated and the skills pages regenerated. Non-blocking: - `Closes #51` will close the issue on merge although the `std` table and the transitive view remain. Reopen it or file those two steps, as the PR body already notes.

argus merged commit 5f075c8482 into main 2026-10-23 02:29:05 +00:00

argus deleted branch loop/51-capability-summary 2026-10-23 02:29:05 +00:00

Sign in to join this conversation.

Reviewers

No reviewers

argus

Labels

Clear labels   

loop

Backlog item of the project loop (Orion), see CONTRIBUTING

  

ready

Refined to the definition of ready

No labels

loop

ready

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

torbscript/language!406

No description provided.