pamoja 0.1.17

The website, rebuilt. The documentation site and the front page are rendered by
cargo xtask site from the same Markdown and the capability map, in one design:
reference pages that open the generated API pages for each language, a hardware
page of spec-sheet cards that says where to buy each part at prices read on a
schedule, an examples page, a reference hub, an architecture drawing, stamped and
minified assets, and navigation that swaps pages without a reload. In the code,
eight capability crates' error types implement core::error::Error, so ? into
a boxed error compiles on the first try, and the .NET packages carry an icon.

Fixed

• Eight capability crates gave their error type a Display implementation and
  no Error one, so fn main() -> Result<(), Box<dyn Error>>, which is the
  first thing most people write, failed to compile the moment it touched mesh,
  Modbus, CAN, GPIO, sensors, serial, session, or LoRaWAN. Every one implements
  core::error::Error now, which needs no std and so reaches a caller on a
  microcontroller too, and a test carries an error from each of them through ?
  into one boxed error.
• The .NET packages declared no icon, so all thirty-eight rendered as a blank
  placeholder in the gallery and in Visual Studio.
• The PyPI upload goes in dependency order, the compiled engine first, and stops
  at the first refusal to create a project rather than retrying into the cap; a
  scheduled workflow finishes the set as the cap allows, so a release never
  waits on it and never meets it once every project exists.
• The site's bar over the generated references was drawn but not visible on the
  Python pages, since pdoc's stylesheet fixes every bare nav element to the
  viewport as its sidebar. The bar is built from elements no generator styles.
• The hardware page linked the Sensor and Actuator traits at a rustdoc path
  that does not exist.
• The Rust reference on the site was weeks stale: the build cache kept the last
  run's site tree, and copying the fresh rustdoc output into a directory that
  already existed nested it under the old pages, which then shipped again. The
  site tree starts empty on every build.

Changed

• The install page says what happens on a platform the compiled engine was not
  built for. The .NET packages restore and compile and then fail on the first
  call, since there is no native library and, unlike Python, no source build to
  fall back on; Alpine and Windows on ARM are the two that catch people out.
• The documentation site is rendered by cargo xtask site rather than mdBook: the
  same Markdown pages, with a guide's four languages as tabs that remember the
  choice, search, syntax highlighting done when the site is built, and a link
  check that fails the build on a broken link or anchor, the generated references
  included. The reference pages list each capability with its install line, its
  module, its worked example, and the same capability on the other three
  registries.
• The reference page for each language opens its generated API pages. A button
  at the top browses the whole reference (the umbrella crate's rustdoc, which
  lists every crate beside it, typedoc's package list, pdoc's package page, and
  the root namespace in DocFX), and every capability row carries a button for its
  API pages, its guide, its worked example, and its registry page, with the same
  capability on the other three reference pages one step away. The generated
  landing pages that duplicated the reference page are gone, and each generated
  tree carries the site's bar. A guide opens on its reader's language before
  first paint, and scrollbars everywhere on the site follow the palette.
• Every link in a committed page is absolute, so the reference and install
  tables render and resolve on GitHub as well as on the site; the site's link
  check follows them like its own. A guide's reference section and a crate's
  README link the capability's row on each language's reference page, which is
  where the install line and the registry are.
• The hardware page says where to buy each part: two or three product pages
  per part from the makers' own stores and the larger distributors, the
  cheapest reputable option first, each with the price the page listed on the
  day it was read, and the lowest price in the summary table. The pages are
  read by hand, so the date is part of the record.
• The reference rows, the domain rows, and the front page's capability cards
  share one card anatomy: what the thing is and its name in code, the install
  line beside it, and under a hairline one row of equal buttons for its API
  pages, guide, worked example, and registry. A card's drawer continues its
  border without a seam, the front page's install lines and buttons sit on one
  grid at every width, and every page has the menu on a phone, the front page
  included. The header over the generated references is the site's own header.
• The site's stylesheets and scripts are published minified: the sources under
  web/ stay readable, and the copies the site serves carry no comments and no
  indentation. A script goes through a real parser on the way, so one that does
  not parse fails the build rather than reaching a browser. The dashboard demo
  at /dashboard is minified the same way as it is copied in, by
  cargo xtask minify <dir>.
• The hardware page is a set of cards rather than tables and bullet lists. A
  card breaks a part down into labelled facts (interface, each figure from its
  document, and its price band with the lowest listed price), says where to buy
  it with the price each page listed, and keeps that apart from what to read
  and build with: the datasheet, specification, or documentation it was written
  from, the driver's source, its crates, and the guides that use it. Each guide
  links the parts its crates drive.
• The search results fit a phone: on a narrow screen they open as a panel under
  the header rather than a dropdown that ran off the left edge. The search box
  shows the slash key that focuses it, a chosen result closes the panel, and the
  shortcut ignores a slash typed with a modifier or into a field.
• Every stylesheet and script a page names carries a stamp of its contents in
  its address, and so do the hooks the four generated references load, so a
  deploy never leaves a browser on a cached copy of the last one; a page the
  router swaps in replaces a stylesheet whose stamp changed.
• A hardware card is a spec sheet: the facts run down one column behind a label
  gutter, and the foot sets where to buy the part beside what to read and build
  with, each a panel of rows of one shape (what it is and a detail on the left,
  the price or the way out on the right), single-column where there is nothing
  to buy. The cards share one padding with the reference rows.
• cargo xtask prices reads every product page the hardware page lists, takes
  the price the page states as Schema.org product data, writes it back with the
  day it was read, and orders each part's offers cheapest first; a page that
  states no price that way, or refuses a scripted reader, keeps its last record
  and is named in the report. A weekly workflow runs it and opens a pull
  request with what moved.
• Every hardware card's foot has two panels. A part with offers keeps "Where
  to buy"; a bus lists the parts on the page that speak it, each a jump to its
  card; a protocol, a specification, or a part no store lists gets "Find parts",
  searches at Adafruit, SparkFun, Digi-Key, and Mouser for its name, under the
  note that says no reputable store lists it and since when. No card shows a
  lone panel stretched across the foot.
• An examples page lists every complete program under examples/ with what
  it shows and the line that runs it, and every guide's example by chapter with
  what it proves and the four files that run it in CI, each a link to the file.
  A reference hub introduces the four generated references and how they are
  made; "Reference" in the header, the front page, and the menus leads there.
  Both are rendered from the code and the guides, so they cannot drift.
• The front page is rendered by cargo xtask site from the capability map and
  web/home.toml, in the same shell as the documentation: the four install
  lines, the first example in four languages spliced from the tests that run it,
  every capability as a card with its four package pages and its guide, nine
  scenarios played by the consoles, the four languages, the roadmap, and the
  backing preview. The Three.js showcase, its data file, and the font host are
  gone; the typefaces are served from the site.
• Moving between pages of the site no longer reloads the document. A link to
  another page fetches it, swaps the article, sidebar, and page metadata in
  place under a short cross-fade, and pushes the address; the back button
  restores the scroll position and a hovered link is fetched ahead of the click.
  Every page is still a complete document with a canonical address and an Open
  Graph card, and the site publishes a sitemap. The header links GitHub, bug
  reports, feature requests, and releases as icons in place of the dashboard
  link, and the front page's hero, first example, capability cards, and backing
  preview were reworked.
• The architecture page opens with a drawing of how a call reaches a crate: the
  three bindings over the compiled engine, a Rust program straight to the
  crates, and every capability by chapter, each box naming its crates, the ones
  whose manifests build on pamoja-core in amber over the core itself, and the
  package that installs the chapter on npm, PyPI, NuGet, and as a feature of
  the pamoja crate. It is rendered from the capability map and the manifests
  by cargo xtask docs, in a wide layout and one for a phone, so it names every
  chapter and crate the map does and is checked like the tables. The link
  buttons take their colours from the same palette as the site's theme.

Pull requests

Capabilities

• Let a capability error cross the question mark operator by @molexxxx in #100
• Render the documentation site from xtask by @molexxxx in #101
• Make each reference page the one door into its generated API pages by @molexxxx in #102
• Rebuild the front door from the capability map by @molexxxx in #104
• Put the site's bar over the four generated references by @molexxxx in #106
• Navigate the site without reloading and rework the front page by @molexxxx in #107
• Open the generated references from the reference pages, say where to buy each part, and give the rows, cards, and bar one design by @molexxxx in #108
• Publish the stylesheets and scripts minified, and build the site tree from empty by @molexxxx in #109
• Lay the hardware page out as cards, link guides to their parts, and fit search to a phone by @molexxxx in #110
• Set the hardware cards as spec sheets and stamp every asset address by @molexxxx in #111
• Read the store prices on a schedule and keep the offers cheapest first by @molexxxx in #112
• Give every hardware card two panels: the parts on a bus, or where to search by @molexxxx in #113
• Minify the dashboard demo as it is copied beside the site by @molexxxx in #114
• Add the examples page and the reference hub by @molexxxx in #115
• Draw the architecture from the capability map by @molexxxx in #116

Documentation

• Point the registry badges at the package, not the account by @molexxxx in #98
• Upload to PyPI in dependency order and finish the set on a schedule by @molexxxx in #103

Continuous integration

• Back off from the PyPI new-project cap rather than retrying into it by @molexxxx in #99
• Run the PyPI backfill upload script from the workflow's own ref by @molexxxx in #105

Full Changelog: v0.1.16...v0.1.17