Repository navigation
Link published Perl, Erlang and Raku packages, add the Raku port, and refresh registry versions - #316
Merged
Merged
Conversation
why: The maintainer ruled on 2026-11-13 that Julia is not released. General
carries none of LibTmux, LibTmuxWorkspace or LibTmuxMCP (each Package.toml
answers 404), yet the release and prerelease install forms advertised
`Pkg.add("LibTmux")` and the inventory marked every package `published`.
Only a registry release is published; the Git install is the one install.
what:
- Point the release, prerelease and git install forms at the Git URL
- Mark each Julia package configured-unpublished with its source linked
- Keep the public repository entry published
- Add package-destinations tests that hold both facts for Julia
why: The maintainer ruled on 2026-11-13 that OCaml is unreleased and installs from source only. The opam repository carries no libtmux package (its packages/libtmux directory and opam.ocaml.org/packages/libtmux both answer 404), yet all six opam packages were `published`, which the inventory reserves for a registry release. what: - Mark each opam package configured-unpublished with its source linked - Keep the existing source-only install and its note unchanged - Extend the package-destinations tests to OCaml
why: The maintainer ruled on 2026-11-13 that Common Lisp is unreleased and installs from source only. The current Quicklisp dist (2026-01-01, 6208 systems) lists no libtmux system, and Quickdocs answers 404 for libtmux, yet the library, its ASDF systems and its workspace command were `published`, which the inventory reserves for a registry release. what: - Mark each ASDF system and the workspace command configured-unpublished with its source linked; keep the public repository entry published - Extend the package-destinations tests to Common Lisp
why: The maintainer ruled on 2026-11-13 that Haskell has no Hackage release. Hackage answers 404 for the libtmux-haskell package, yet the release and prerelease install forms were a bare `build-depends` line that only resolves from Hackage, and the library was `published`, which the inventory reserves for a registry release. what: - Point the release and prerelease install forms at the source-repository-package form - Mark the Cabal package configured-unpublished with its source linked - Keep the Hackage page as a rejected candidate, so the verifier reports the day it answers - Update the port-metadata status pin and extend the package-destinations tests to Haskell
…der instead of asking a host for it why: A package's pinned manifest can still say `0.0.0+development` after its first release, because the documented revision predates the version bump. Erlang is that case: libtmux_erlang 0.0.1 is on Hex, and v0.0.1 contains the documented revision with only release preparation on top. Asking Hex for `0.0.0+development` would call the real package absent and block linking it. A placeholder names no release, so the verifier records that it declines to check one, with the manifest that says so, until the pin moves to a released revision. what: - Flag a `+development` version in manifestVersion and keep it out of the versions a host must carry - Write the declined check with the placeholder's manifest as its note - Let the every-host version test accept that note, and only that one, in place of a confirmed version - Test that the placeholder is skipped and that real and prerelease versions are still asked for
why: LibTmux:ver<0.0.1>:auth<zef:libtmux> is on Raku Land and in the zef ecosystem index, so the shared catalog can list Raku and link its package. The rule is that a port appears only with a published package, and libtmux/docs issue 315 asks for the catalog entry before any link to a Raku docs route. what: - Add the raku port: zef install of the auth-qualified name as the registry form, a source checkout as the explicit alternative, workspace and MCP excluded because the repository ships neither - Add the Raku Land mark and host, with an identity rule that checks the page title, the version selector and the repository link, and its negative cases - Read META6.json for the manifest inventory and probe the zef ecosystem index for the registry state; only the raku entries are added to the generated data - Record the verified Raku Land and GitHub destinations and the header expectations - Seed the Raku trunk entry in versions.json and the shell port list, and group Raku with the scripting languages in the picker
why: The Raku library ships its own exporter, tools/export-docs.raku, which reads declarations with Rakudo's RakuAST and documentation from native RakuDoc. The site needs an adapter that checks that artifact rather than parsing Raku in JavaScript, and a model committed at the revision it describes. what: - Add the libtmux.raku-api/v1 adapter: it rejects uncommitted inputs, altered sources, unresolved RakuDoc links and invalid signature spans, and derives the native signature spans the shared renderer uses - Verify in gen-api-model that the exporter bytes and compiler match the committed source and its .tool-versions pin - Bind 162 shared concepts to Raku declarations and mark the rest absent - Place a module exported by another module once in the export-group sidebar, with a test that fails without the fix - Render Raku signatures natively and name the port in the shared tables - Commit the model, sidebar and path sidecars generated from libtmux-raku at 9a9838047f15 (1069 public declarations, none lacking documentation)
why: The libtmux Raku artwork is merged in libtmux/assets, and the port needs its tile, social cards and palette before it has pages. what: - Copy the library set from libtmux/assets at 55dd6eac4347 with its digests, and apply the shared-root web manifest overrides the other new languages use - Add the Raku palette, regenerate the brand CSS and catalog digests, and show the library tile in the port switcher - Record the source revision and overrides in notes/branding.md - Extend the title and project-name expectations
why: The Raku repository owns its installation guide, example programs and compatibility policy as Markdown. The site should publish those at the revision of the model rather than keep a second copy. what: - Stage README.md as Getting started, examples/README.md as Runnable programs and the tmux compatibility ADR as a topic, from 9a9838047f15 - Add the Core page with cards for the staged sections and the reference, and state the experimental status and the absence of a workspace manager or MCP server - Route a selected-source Raku build through the same native model and guide steps as the other native ports - Cover the Raku product exclusions and the single-card guide index
why: libtmux_erlang 0.0.1 reached Hex on 2026-11-13 (CST); its metadata links libtmux.org and the v0.0.1 tag carries the documented source. The site still said the application was unreleased and offered only a Git install. Hex carries no HexDocs for the package (docs_html_url is null and hexdocs.pm answers 404 for it), so only the package page is linked. what: - Name Hex as the Erlang registry and link the package page from the library entry and header - Offer the Hex release first, pinned exactly as the package README does, and keep git_subdir as the explicit Git tab - Make installsFor fill both the version and the revision, so a registry tab and a source tab can share a port - Drop the Elixir-syntax pin advice from the Erlang page, whose install already pins an exact version - Record the Erlang entry from gen-registry.mjs (release 0.0.1, tag v0.0.1) and a verified Hex evidence record - Remove the unreleased claims and update the header, destination and port-links fixtures - Test the registry, install forms, rendered page and evidence, and that no HexDocs reference is linked
why: LibTmux, LibTmux-Async and LibTmux-Workspace 0.003 are on CPAN, but the committed model, guide cache and manifest packages described libtmux-perl d9fa7c527. Its installation guide called the distributions unreleased and offered only a source checkout, and the landing example stated that no CPAN release was claimed. The live installation page repeated both. what: - Pin Perl to libtmux/libtmux-perl@a1cab0324 and regenerate its API model and path data (exported with Perl 5.44.0 and PPI 1.291), tmux usage, guide cache, example sources, manifest packages and mention index with the repository's generators - Adopt the source change between the pins: the installation guide installs each distribution from CPAN and keeps the source checkout as an alternative, the examples page lists the programs shipped inside each distribution beside the repository's qualification programs, and the filtering, graph, errors and orchestration guides were revised - No declaration changed; only the LibTmux, LibTmux::Async and LibTmux::Workspace module documentation differs in the model, and the manifest packages move from 0.001_001 to 0.003 - Keep every reviewed tmux usage claim: all of them hold at the new revision, so only the usage file's revision binding moves - Drop "No CPAN release is claimed" from the Perl landing example; the displayed program still needs the source checkout's fixture, so its recorded revision stays where the program was recorded - Update two assertions that read the guides: the orchestration page now opens with "Start with a complete program", and the guides name a CPAN changelog file, the `libtmux.where/v1` wire format and a filter criterion path in code spans, which are not API and stay unlinked Source refs: libtmux/libtmux-perl master a1cab0324b600a5df6e34b92590b5c3bd8f79c69, previous pin d9fa7c5278d243c671a29cdb00e3a911ac651bfa.
why: libtmux_erlang 0.0.1 is on Hex, but the committed model, guide cache and manifest packages described libtmux-erlang f1a2e66c0. Its installation guide offered only a Git dependency and its compatibility guide said no registry publication was claimed, so the live installation page told readers there was no published package. The manifest recorded 0.0.0+development, which a host answering for 0.0.1 contradicts. what: - Pin Erlang to libtmux/libtmux-erlang@539c7297c and regenerate its model and path data (exported with OTP 29.1.2 and the same exporter digest as before), tmux usage, guide cache, manifest packages and mention index with the repository's generators - Adopt the source change between the pins: the installation guide names the Hex package and keeps the Git subdirectory dependency as the source alternative, the compatibility guide says the core package is the only registry publication and HexDocs is not published, and the README documents the Hex install - No declaration changed; only the application file and Rebar config digests differ in the model's provenance, and the manifest package moves from 0.0.0+development to 0.0.1 - Keep every reviewed tmux usage claim: no source file under src/ changed, so only the usage file's revision binding moves - Link the fifteen example programs on the examples index at the new revision; the examples directory is unchanged, so the landing example and its recording stay at the revision where the program was recorded Source refs: libtmux/libtmux-erlang master 539c7297ceae65a1cf683e0836eae0a1ccd34d64, previous pin f1a2e66c0fa15d1e8d4efa2725a159121815293b.
why: The Raku reference needs the same sidebar buckets, short names and index cards as the other ports, so a reader finds Server, Pane and the options facades in the same places. what: - Name a top-level class by its last path segment and keep its package path in the id, as Perl does - Place the 27 declarations the shared buckets did not match, and explain the seven that span several tasks - List a type declared under its exporting module as a card, as Common Lisp does - Keep an exception's X:: path as its short name, because it is written in full and not through the module that exports it - Write Raku symbols as authored and extend the name and form tests - Regenerate the model and sidebar sidecars from libtmux-raku at 9a9838047f15
why: Every port's landing page needs a Core overview that names the real declarations behind each capability, and a complete program a reader can run. The quickstart in the Raku repository is that program, and it was run against the published package rather than a checkout. what: - Name the Raku Server, Session, Window, Pane and WindowLink declarations and the declarations behind twelve capabilities, validated against the model - Add the homepage program, examples/quickstart.raku at 9a9838047f15, with its expected output. It was run after `zef install` of LibTmux:auth<zef:libtmux> 0.0.1 on tmux 3.8 and tmux 3.3a and printed `editor: 2 panes` on both - Match the Core page description to the capabilities it claims - List Raku among the ports with a server snapshot
why: Each kind, modifier and inherited badge in the Raku reference links to a glossary term that explains what the word means in Raku. what: - Define module, class, method, property, constant, enum, typealias, function, exception, trait, inherited, overload, async and package for Raku, each with a docs.raku.org reference - Hold Raku links to Raku documentation in the language table
why: The tmux command pages list, per language, the library methods that send each command. Raku needs the same record, read from the library source with Rakudo's own parser rather than text matching, and it must stay bound to the revision of the model. what: - Add a Raku source reader that parses each library module with the compiler pinned by the library revision and credits only code, never comments, documentation or quoted examples - Carry the reviewed claims, guards, not-sender reviews and preflights for Raku's dynamic Invocation plans, each citing a line of the pinned source - Generate site/src/data/tmux-usage/raku.json with scripts/gen-tmux-usage.mjs at 9a9838047f15: 170 symbols, no unreviewed command-named method - Install the compiler and JSON::Fast in the docs test workflow and document the local setup
…kflows why: A Raku release or trunk build must run the library's own exporter with the compiler its revision pins, and the publisher must accept the raku prefix. Without these steps a caller workflow in libtmux-raku would fail before it published anything. what: - Read the exact compiler from the selected source's .tool-versions, install it with Raku/setup-raku, install the declared dependencies and run tools/export-docs.raku in the selected checkout - Run the Raku adapter tests in the same job - Admit the raku slug in the publisher's port list and reserved top-level names, so only raku/<version> prefixes can be written - Check out the integrated libtmux-raku revision in the docs test workflow and skip its native model freshness check as the other native ports do - Add raku to the source-bound port contract the deploy tests hold
why: Each reference entry lists the guide pages that mention it, and the index is generated from the staged guides. what: - Regenerate site/src/data/mentions.json with scripts/gen-mentions.mjs after staging the Raku guides; only Raku mentions are added
…hrough MetaCPAN's API why: MetaCPAN answers a script's page request with a client challenge, so a 200 from metacpan.org proves nothing. The header will link a CPAN distribution page and a module's POD page, and each needs an identity rule before the inventory may name it. A manifest at a development commit can also declare a developer version (0.001_001) that PAUSE never indexes, which the version check would report as absent from the host. what: - Add a `metacpan` verifier for /dist/ and /pod/ pages. It reads fastapi.metacpan.org: the release names the distribution and its repository, the module endpoint says which module documents the page, and the rendered POD must declare that module in its NAME section. - List MetaCPAN among the hosts that report a repository and list versions. - Record a manifest's developer version as `developer` rather than `absent`, only on a host that issues none, and refuse that record for a release number. - Add negative cases: the right distribution and POD, a different package, a different repository, none, a missing version, a challenge page, a NAME that declares another module, a package documented in another module's file, and a developer version on MetaCPAN and on a host that lists them.
why: The maintainer ruled on 2026-11-13 that Julia is not released and that a git tag (v0.1.1) is not a registry release. The generator read a final tag as a final release, so Julia would badge "0.x" and say "Released" while General carries nothing. OCaml, Haskell, Common Lisp, Clojure and Perl are the same case; four of them were unreleased only because they have no tag or a hand-written `maturity`. The inventory already says which ports have no registry release, so the generator gates on it instead of on the port. Swift and C++ stay as they are: SwiftPM and their own vcpkg registry resolve a release from its tag, and both are `published` in the inventory. what: - Write an unpublished entry as `maturity: "unreleased"` when the port's core inventory entry is not `published`, including an entry kept from the baseline - Record that in the committed data for Julia, Haskell and Common Lisp - Rewrite the Julia badge, prompt, navigation and notice tests, which asserted a "0.x" badge and "libtmux is released" from a tag, to read unreleased - Add tests that a tag does not release a port no registry carries, that a kept baseline entry is gated, that the read can still fail on an ungated port, and that Swift and C++ are untouched - Narrow the support page and scripts README to the rule that remains
why: The maintainer asked for a sweep of every version. registry.json still carried the 2026-11-07 state: TypeScript, Rust, Java, Kotlin, Scala and Ruby read 0.1.0, Go v0.1.0 and Lua 0.1.0-1, while the registries now serve 0.1.2 (Go v0.1.3, Lua 0.1.1-1, C# and F# 0.1.1, Elixir 0.1.1, Swift 0.1.1). Install snippets, prompts and badges are generated from this file. what: - Run gen-registry.mjs in full: its probes and the release tags agree with each registry and with GitHub's tags - Move Elixir, Lua, Ruby, TypeScript, Rust, Go, Java, Kotlin, Scala, C#, F#, Swift and Julia's tag to their current values - Keep OCaml, Perl and the unreleased ports as the generator leaves them (the opam probe cannot tell an outage from absence, by design) - Make the Ruby and Lua metadata tests read the generated data instead of pinning 0.1.0 and 0.1.0-1
…links and install guidance why: LibTmux, LibTmux-Async and LibTmux-Workspace are on CPAN, but the Perl header offered only GitHub directories, the install picker offered only a source checkout, and the pages called the packages unpublished. A reader could not tell the registry package from the native POD or the source. what: - Register MetaCPAN as a package host and, under the same host id, as an API host for POD, with a CPAN mark and a page mark drawn for this site so the distribution chip and the POD chip differ at icon size. - Mark the three distributions and the workspace command published, with a distribution page and the POD of the main module each; the command shares its distribution's page. Source links stay. - Give the port a MetaCPAN registry and POD reference, each package its distribution and POD page, and the install picker `cpm install --global` for LibTmux, LibTmux::Async and LibTmux::Workspace, with the source checkout kept as the explicit alternative. Mark the workspace command published and drop the "numbered 0.1.N" claim from its guidance, since a CPAN release is a decimal version such as 0.003. - Remove the "Unpublished development distribution", "No CPAN release" and "do not identify published CPAN releases" text from the port metadata and the two Perl overview pages. - Probe MetaCPAN in gen-registry.mjs: decimal versions sort as numbers, developer and BackPAN releases are skipped, and the tag is the registry's version text after a `v`, so 0.003 and v0.003 are recorded as they are. Record only Perl's refreshed entry in registry.json, and replace the Perl cases of gen-registry.negative.mjs, which used Perl as the port with no probe, with a synthetic source-only port plus CPAN cases. - Record passing evidence for the six MetaCPAN destinations. - Hold the Perl header actions, rows, mark order, port links, destinations, install commands, registry entry and the unchanged MCP exclusion in tests, and move the unreleased-package notice test to a port that is unreleased.
why: A reference page may link a method to its section of the POD on MetaCPAN only if that release has the section, and the site's tests and renderer must not request MetaCPAN, whose pages answer scripts with a challenge. The API MetaCPAN serves does render the POD with the page's own renderer, so a heading's id there is the fragment the page answers to. what: - Add scripts/gen-perl-pod.mjs and scripts/lib/perl-pod.mjs. For each distribution the Perl port declares in ports.ts, they read the latest release's provided packages, the document that documents each (a package with no POD is null; an exception subclass names the shared document), and for each document its file path, the SHA-256 of the file the release shipped, and the heading and item ids of the rendered POD. - Refuse a distribution that is not the latest released one, a package filed under another release, a document outside lib/, and a POD whose NAME section names another module, including a client challenge page. - Commit the record as site/src/data/perl-pod.json. - Check the committed record offline in test-all.sh, with a negative script that shows the check failing on a dropped distribution, a bad digest, a package naming a missing document, a repeated fragment, a dotted release and a file the generator would not write. The weekly destination workflow also checks the record against MetaCPAN and names the old and new release. - Describe the generator in scripts/README.md.
…lease why: The shared reference and MetaCPAN render the same Perl distributions, but a reader of a filter or server method had no way to open the POD that ships in the release, and the reference showed no sign of which release a link names. what: - Add a MetaCPAN POD action beside `[source]` on a declaration, from the API model's recorded package, parent, inheritance and owning file and the recorded release, with no list of pages. A module or class links its POD page; a method links its section when the release's rendered POD has that fragment and the heading is not repeated. - Resolve the owning module from the declaring package, so an inherited method opens the base class's POD, the synchronous and asynchronous classes of one name stay distinct, and an exception subclass opens the shared LibTmux::X document, with its heading where the release has one. A method a subclass declares in a shared document falls back to the module, because a heading of the same name may belong to the base class. - Link nothing for a package with no recorded release, a document in another file, or a declaration the release cannot be shown to contain: a method with no heading is linked to the module page only where the declaring file's SHA-256 is the release's. - Label a link with the release version when the page documents other source than the release shipped. A page for a decimal release tag pins the link to the recorded release; trunk and previews use MetaCPAN's latest. - Cover module and method targets, inherited members, shared-file exceptions, unavailable targets, release against trunk, the record reader (a challenge page, a wrong NAME, a package filed under another release), and the rendered cluster, and bind the helper in the sidebar harness.
…red checks why: The first full test run showed Raku missing from four shared tables, and embedding every module in the model, a mechanism for unpublished source, kept the reference from linking the public GitHub revision the way Perl does. what: - Drop the embedded module copies from the Raku model after they have proved the recorded digests; source links open GitHub at the model revision, and the model is 1.2 MB instead of 1.6 MB - Highlight Raku code with the Raku grammar - Record the Raku port-link snapshots and the homepage proof, including the two tmux releases the quickstart was run on, and scope the llms-full.txt row of the linking guide to it
why: Perl published 0.003 to CPAN and Erlang published libtmux_erlang 0.0.1 to Hex, but the docs pinned guides, models and manifests from before those releases, so live pages still called both unpublished. what: - Pin Perl source-bound data to libtmux-perl a1cab0324 - Pin Erlang source-bound data to libtmux-erlang 539c7297c
why: The Perl distributions are on CPAN; readers need registry destinations, registry installs and links from API entries to the POD shipped in the release (#313, #314). what: - Add MetaCPAN package and POD hosts, Perl registry and CPAN installs - Record each release's POD and link API entries to its sections
why: LibTmux 0.003 is on CPAN, but the landing example still told readers to install the core distribution from source and the recording described libtmux-perl 36b978c5e, before the release. The example needs a registry install with a version floor and a verification record at the pin the rest of the Perl data now uses. what: - Move the landing example to libtmux/libtmux-perl@a1cab0324: the source tree, and the author fixture module, which gained fuller cleanup diagnostics; examples/quickstart.pl is byte-identical - Add the setup command `cpm install --global 'LibTmux~>= 0.003'` and list cpm and CPAN access as prerequisites; the CPAN 0.003 lib/ tree is identical to packages/core/lib at the pin - Record the program again with scripts/gen-core-recording.mjs from a clean worktree at the pin (15 steps, Perl 5.44.0, tmux 3.8a); the recorder's --check passes. The file is recorded afresh so its single revision moves with its only program - Recompute the verification record: file and clipboard digests, the two-command recipe with its expected output, and the three variants - Verified with check-example-prose.py --example home --port perl in every view (full, concise, errors, cleanup) on each tmux release the record lists, 3.3a through 3.8 (48 runs), with cpm 1.1.6 installing into a private prefix so the shared Perl was not changed Source refs: libtmux/libtmux-perl master a1cab0324b600a5df6e34b92590b5c3bd8f79c69, previous landing revision 36b978c5eb6aa33873229046037e7d26136ca2cf.
why: The Perl repin moved the manifests from the developer version 0.001_001 to the released 0.003, so the evidence recorded for the CPAN destinations no longer matched what the manifests declare. what: - Re-verify the 11 Perl destinations through fastapi.metacpan.org and GitHub, recording 0.003 as confirmed for the six MetaCPAN pages
why: libtmux_erlang 0.0.1 is on Hex, but the landing example built the library from a Git dependency pinned to libtmux-erlang e858027b2 and listed Git as a prerequisite. The example needs a registry install with a version floor, and the recording and verification record need the pin the rest of the Erlang data now uses. what: - Move the landing example to libtmux/libtmux-erlang@539c7297c: its source tree; examples/readme_demo.erl is byte-identical - Replace the git_subdir dependency in the displayed rebar.config with `{libtmux_erlang, "~> 0.0.1"}`, point the run command at the Hex layout (`_build/default/lib/libtmux_erlang/ebin`), and list access to hex.pm instead of Git; the Hex 0.0.1 src/ and c_src/ trees match the pin, and only the application file differs in formatting - Record the program again with scripts/gen-core-recording.mjs from a clean worktree at the pin (14 steps, OTP 29.1.2, Rebar3 3.28.0, tmux 3.8a); the recorder's --check passes. The file is recorded afresh so its single revision moves with its only program - Recompute the verification record: file and clipboard digests, the recipe and the variants - List tmux 3.3a, not 3.3, in the record: the library refuses 3.3 with unsupported_tmux_version and supports 3.3a through 3.8 - Verified with check-example-prose.py --example home --port erlang in every view (full, concise, errors, cleanup) on tmux 3.3a and 3.8, with Rebar3 fetching libtmux_erlang 0.0.1 from Hex into a private home directory Source refs: libtmux/libtmux-erlang master 539c7297ceae65a1cf683e0836eae0a1ccd34d64, previous landing revision e858027b2b204c3e621b1f74e9419c9b71e3f2f5.
why: The Raku library is published on zef as LibTmux:auth<zef:libtmux> with a Raku Land page, and a published port gets its place in the shared catalog, reference and landing page (#315). what: - Add the Raku port entry, Raku Land registry mark and zef installs - Add the API reference from the library's RakuAST exporter, guides, branding, Core home, recorded landing example and usage scan - Resolve conflicts by keeping both the MetaCPAN and Raku Land hosts, marks, verifiers and origins; regenerate mentions after staging
…wed link table why: The reviewed link table is kept in address order so a review reads as the rows that changed; the MetaCPAN rows were appended at the end. what: - Sort the table by address, then by address and label, as its test orders it
why: The outer test that loads each port's cross-reference inventory in Sphinx listed Perl as the last port and had no Raku case, so a Raku entry Sphinx could not read would reach the site unnoticed. what: - Add raku to the ports whose inventory the test writes and loads; all 12 cases pass with the locked Python tooling
why: libtmux-raku #11 wrote tmux format names as code in the generated field accessor docs, which the site links to its format catalog. The format catalog coverage check was 0.807 against its 0.9 floor with the old docs; the model needs the merged revision to carry the code spans. what: - Export the native API at libtmux-raku master 8293da87dc45, the merge of #11, from a master-pinned checkout, and regenerate the model, its path sidecar, the manifest inventory, the staged guide cache and the tmux usage record there; the usage evidence lines are unchanged - Leave the landing example, its recording and the home fixture at 9a9838047f15: the program bytes are the same - Format coverage is now 0.937 (1012 catalog and 104 other links, 75 plain of 1191 mentions) Source refs: libtmux/libtmux-raku master 8293da87dc45f61ea2a68d1cc5327b4e62892732, previous pin 9a9838047f1585c2c790b011cb708670999b7bdd.
why: The Raku reference wrote tmux format names as plain words, which dropped site-wide format catalog coverage below its 0.9 floor; the library now marks them as code (libtmux-raku#11). what: - Repin the Raku model, manifest, staged guides and usage scan to libtmux-raku 8293da87d - Include raku in the Sphinx inventory port list
…hortened name why: At 390px the documentation picker trigger ellipsized its whole line, so the "unreleased" badge Julia now carries was clipped under the product name instead of following it at the gap the list uses. what: - Lay the trigger name and badge out as a row in which the name truncates and the badge keeps its size - Keep the one-line ellipsis for the trigger's version line
…ymbols plain why: The release build failed its dangling-reference ceiling at 67 of 60. Main measures 58; the nine new entries came from this branch: Raku's guides name Promise and Supply, which no inventory covered, and Perl's 0.003 guides name a CPAN Changes file, the libtmux.where/v1 wire format and the pane.where.width.-gte query path. None is a missing libtmux symbol, so raising the ceiling would have hidden them. what: - Add a curated Raku entry for Promise and Supply, pointing at docs.raku.org, so the guides link them as other ports link their language types - Add NOT_API rules for a CPAN changelog file, a versioned wire format name and a query path with an operator segment; they gate reporting only, so a name a port defines still links - Test both, with controls for a type, a qualified name, a field path and an Erlang arity that must stay candidates
…erl link fix why: The index records each unresolved mention, and the previous commit resolved Raku's Promise and Supply and left Perl's three non-symbols plain, so its check called the committed index stale. what: - Drop the eight Raku and Perl entries the linker no longer reports
tony
temporarily deployed
to
docs-preview-cleanup
November 14, 2026 16:03 — with 
GitHub Actions
Inactive
GitHub Actions
Inactive
This was referenced Nov 14, 2026
This branch was previously deployed
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.
Perl, Erlang and Raku now publish packages: Perl's
LibTmux,LibTmux-AsyncandLibTmux-Workspace0.003 on CPAN, Erlang'slibtmux_erlang0.0.1 on Hex, and Raku'sLibTmux:auth<zef:libtmux>0.0.1 on zef (Raku Land). The site still called Perl and Erlang unpublished, had no Raku port, advertised registry installs for ports that are not released, and showed registry versions from before the latest releases. This integration branch brings the site in line with what the registries publish.Closes #313. Closes #314. Addresses #315 (shared-site part; the native README and metadata part landed in libtmux-erlang#14 and libtmux-raku#10, and libtmux-perl already carried it).
What changes
Perl on CPAN (#313)
cpm install --global LibTmux(plusLibTmux::AsyncandLibTmux::Workspace), with the source install kept as an alternative.scripts/gen-registry.mjs(decimal versions, skips developer and BackPAN releases) and a MetaCPAN verifier that readsfastapi.metacpan.org, because MetaCPAN's HTML answers scripted clients with a challenge page.Per-symbol POD links (#314)
scripts/gen-perl-pod.mjsrecords each release's documented packages, file digests and heading ids insite/src/data/perl-pod.json.MetaCPAN PODaction besidesource: 569 methods and 26 exceptions link to their section, 27 classes and 5 methods to a module page; sync and async classes of the same name stay distinct; entries whose file differs from the release are labelled with the release version.Erlang on Hex
{deps, [{libtmux_erlang, "0.0.1"}]}.install,git_subdirkept as the source alternative. No HexDocs link: the package has no HexDocs.Unreleased ports (maintainer, 2026-11-13: OCaml, Common Lisp and Julia are not released; Hackage has no Haskell release)
Pkg.add("LibTmux")) is replaced by the Git URL install; Julia, OCaml, Haskell and Common Lisp inventory entries move frompublishedtoconfigured-unpublished.gen-registry.mjsderives anunreleasedmaturity from the core inventory status, so a Git tag no longer badges a port as released (Julia, Clojure, OCaml, Haskell, Lisp). Swift and C++, which resolve releases from tags, are unchanged.Registry version refresh
gen-registry.mjsrun: TypeScript, Rust, Java, Kotlin, Scala and Ruby 0.1.2; Go v0.1.3; Lua 0.1.1-1; C#, F#, Elixir and Swift 0.1.1. Tests that pinned 0.1.0 now read the generated data.Source pins
d9fa7c527toa1cab0324(the 0.003 release); Erlang's from libtmux-erlangf1a2e66c0to539c7297c(0.0.1 plus the Hex guide fixes).Raku port (#315)
zef install 'LibTmux:auth<zef:libtmux>'; workspace and MCP are excluded (the library publishes neither).tools/export-docs.raku, 1069 declarations at libtmux-raku8293da87d, which writes tmux format names as code: libtmux-raku#11), guides, branding from libtmux/assets, Core home and a recorded landing example installed from Raku Land (passes all four views on tmux 3.3a and 3.8), usage scan, CI toolchain steps, andrakukeys in the xref and type-link ratchets from a local Raku tree build.Verification
astro check, and the generator and checker--checkruns (verify-destinations,verify-api-destinations,gen-registry,gen-mentions,gen-example-sources,gen-manifest-packages,gen-shell-ports,gen-perl-pod,check-example-blocks,check-nav,check-palette) with their negative suites.After merge
IAM trust for the merge revision and Raku's publisher roles, then caller repins and publishes; Raku's first trunk and
v0.0.1publishes follow its caller PR.