registry: a package's capability summary #51
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Context
Which
stdpackage is which capability (RELEASE.md section 7.8), summed up per published package and shown by the registry.Source
Acceptance criteria
torb publishrecords the summaryDependencies
None known.
Moved from the planning lists of the docs; the design record stays the specification.
[loop:torbscript] intake: in scope (author orion, label loop), sources NETWORK.md slice 11 and RELEASE.md 7.8, not a duplicate, no collision with a design record. Touches
torb publish, the registry index and the registry page (tools/registry, depends on the registry slices of #16); no seed impact expected. next: refine, waiting (ready buffer full: #4, #163, #164, #223 are ready) until 2026-10-10T04:00:00Z[loop:torbscript] claim refine by session:loop-torbscript-20261023 until 2026-10-23T03:19:32Z
[loop:torbscript] decided by the loop: scope of this issue is the remaining gap, not the whole slice. Checked on
main(2bdab4d6):torb publishalready derives and prints the capabilities (capabilitiesOf,compiler/src/package/archive.trb, docs/tooling/torb-publish.md), the registry re-derives them on receipt (tools/registry/src/upload.trb), the index linecapabilities "..."carries them, and the package page shows them as chips for the latest version only (currentLines,tools/registry/src/packages.trb). Open: (1) no capability table in the docs as a table, (2) thereleasestable keeps no capabilities, so the versions table cannot show them per version and cannot flag a gain, (3) RELEASE.md 7.8's "gained since" line. Why this cut: it follows RELEASE.md 7.8 and NETWORK.md slice 11 and fits one PR.[loop:torbscript] decided by the loop: left out of this issue, each its own later step (just in time, none filed now): moving the table from the toolchain into
std("lives in std", RELEASE.md 7.8, plus the test that every machine-reachingstdpackage is listed), and the transitive view over the dependency graph. Why: the table move touches the compiler's lookup and is a separate commit set; the transitive view needs the resolved graph. Neither blocks the per-version summary. Capabilities of releases published before the column exists are "not recorded" (nullable column, migration like the earlierALTER TABLEones indatabase.trb), shown as such, and no gain is flagged against an unrecorded predecessor: guessing "none" would be a false claim on a security display.[loop:torbscript] refine: ready. Goal: every version on a package page shows what its own imports reach, and a version that gains a capability over its predecessor is flagged (RELEASE.md 7.8; NETWORK.md slice 11).
Design record point: RELEASE.md 7.8 ("The capability summary") and the 7.x registry site section, which says "The capability summary (#51) is not built"; update that sentence and NETWORK.md slice 11 state in the same PR. Seed: no (no syntax, native, driver flag or string-looked-up std name; registry and docs only).
Acceptance criteria (testable):
torb-publish.md) lists each capability name with itsstdmodules/names, taken fromcapabilityOf/capabilityOfImport, including the "pure values" rule; a registry test or docs check keeps the table andcapabilityOfin step.releasesgets a nullablecapabilitiescolumn (migration for existing databases, same pattern asdeprecated), written at publish fromupload.release.capabilities; a test publishes two versions and reads both back.nonefor an empty recorded set,not recordedfor NULL), escaped like other stored text.GET /api/1/packages/...(if it lists releases) or the existing release listing carriescapabilitiesper version; otherwise the page only.stdtable and transitive view listed as the open remainder.tools/registrytests andsh tools/gates.sh ain forge CI.Size: one PR, two commits:
docs(tooling): the capability tableandfeat(registry): capabilities per version and the gain flag. Dependencies: none (registry slices of #16 are in). The two left-out steps stay on the epic's checklist (#51 remains open until they are filed or decided dropped; the implementer closes only this step's boxes and notes the remainder).Tokens: roughly 60k in this refine run. Releases claim
claim refine by session:loop-torbscript-20261023.[loop:torbscript] claim implement by session:loop-torbscript-20261023 until 2026-10-23T07:29:18Z
[loop:torbscript] implement: PR #406 is open and CI is green (gates, tier A and B, tools/registry, pdisc). Two commits:
docs(tooling): the capability tableandfeat(registry): capabilities per version and the gain flag. What it does:docs/tooling/package-capabilities.md, linked fromtorb-publish.md, andtools/registry/tests/capability-table.test.trb, which reads its tables and compares them withcapabilityOf/capabilityOfImport.releases.capabilitieswith a migration (NULL is not recorded, never none), written at publish; tests publish several versions and read the stored sets and pages back, and migrate an old database.none,not recorded, escaped) andgained: <names>against the nearest earlier unyanked version. Tests: gain, no gain, loss, unrecorded predecessor, first version, yanked predecessor, escaping.Open remainder, so #51 should stay open (the PR says
Closes #51as the contract asks; reopen on merge or split): the capability table instditself and the transitive view over the dependency graph.next: review
Token usage: not available to the subagent (spans two context windows).