@nanisoft/prism-llms 0.4.0 → 0.5.0

package/dist/md/blocks/stack-grid-01.md

@@ -0,0 +1,108 @@
+# StackGrid01
+
+A survey of what a product is assembled from, and a second grid of what it built itself.
+
+```tsx
+import { StackGrid01 } from '@nanisoft/prism-ui/blocks/stack-grid-01'
+```
+
+## Overview
+
+StackGrid01 is a survey of what a product is assembled from, and what it built
+itself. The composed parts sit in one grid, each a name and a role; the in-house
+work sits in a second grid, each a name and a line about it.
+
+Three of the four NaniSoft sites publish this section, and each one drew it by
+hand with the same two groups. Three of them also drew the second group
+differently from the first - a dashed border, a different tile, a mark above the
+name - because the visual difference is the claim: *this part is ours*.
+
+That is what the `own` group is here. It is a separate prop and a separate grid
+rather than a flag on the part, because the difference is a claim about provenance
+and a claim is not a property of a row: a part that is assembled and a part that is
+built are the same kind of thing with a different answer to "who wrote it".
+
+## Guidelines
+
+### When to use
+
+Use StackGrid01 where a reader's question is "what is this made of" and the honest
+answer is mostly other people's work with a few exceptions.
+
+Use it when the exceptions are the point. If everything in the grid is composed,
+drop `own` and use `NoteGrid01` instead: a second group with nothing in it is a
+claim you have not made.
+
+### When not to use
+
+Do not use it for integrations the reader connects themselves. That is a
+`ProductGrid01` of destinations, and a survey of parts is not a survey of things
+you can turn on.
+
+Do not use it where you cannot substantiate the in-house group. The block requires
+`ownLabel` precisely because the group is a claim, and a claim nobody can check
+is marketing.
+
+### Best practices
+
+- Pass the words you mean for the claim. Three of the four sites write three
+  different ones - "built in-house", "built by Nanisoft", "our own" - and the
+  block does not choose between them.
+- Keep a role to a phrase. The grid is a survey of what a product stands on, not a
+  feature list, and a role that runs to a sentence turns a survey into prose.
+- Order the composed parts by how much of the product they carry.
+
+### Content guidelines
+
+- Use each part's own name, as its authors spell it.
+- Write a role as what the part does *here*, not as what the part is generally
+  capable of.
+- Write a blurb as why it is not assembled. That is the question the group raises.
+
+**Two groups: the parts it stands on, and the two it built itself.**
+
+```tsx
+import { StackGrid01 } from '@nanisoft/prism-ui/blocks/stack-grid-01'
+
+/** Two groups: the parts it stands on, and the two it built itself. */
+export default function StackGrid01Demo() {
+  return (
+    <StackGrid01
+      headingLevel="h3"
+      eyebrow="Preview"
+      title="How it is built"
+      description="Most of it is composition. Two things are not."
+      ownLabel="built in-house"
+      caption="Everything else in the factory is composition."
+      parts={[
+        { name: 'Postgres', role: 'Storage' },
+        { name: 'NATS', role: 'Queue' },
+        { name: 'Docker', role: 'Isolation' },
+        { name: 'OpenCode', role: 'The agent' },
+      ]}
+      own={[
+        { name: 'The orchestrator', blurb: 'Decides what runs next, and what waits.' },
+        { name: 'The merge pipeline', blurb: 'Three review rounds, then auto-merge.' },
+      ]}
+    />
+  )
+}
+```
+
+## Props
+
+**`eyebrow`** `string` · optional · default: — — Optional label above the section title. See the No-Default-Eyebrow Rule.
+**`title`** `string` · optional · default: — — The section title. Omit it for a grid composed under its own heading.
+**`description`** `string` · optional · default: — — One or two sentences under the title.
+**`parts`** `readonly StackPart[]` · required · default: — — The parts the product is assembled from, in the order a reader should meet them. Order is the caller's because it is a claim about which part matters first.
+**`own`** `readonly StackOwn[]` · optional · default: — — The things the product built itself, in the order a reader should meet them. Omit it for a product that assembled everything, and pass it when the claim is that some of the work is its own.
+**`ownLabel`** `string` · optional · default: — — The label on the in-house group, which is the claim the group makes. Omit it when the group is titled by the section itself, and pass a word you mean: "built in-house", "built by Nanisoft" and "our own" are three different claims and the Block does not choose between them.
+**`caption`** `string` · optional · default: — — The line under the grid, for the sentence that qualifies it: what is not here, or where to read the full list.
+**`headingLevel`** `HeadingLevel` · optional · default: — — Heading level for the section title. See `HeadingLevel`.
+**`className`** `string` · optional · default: — — Layout only, exactly as on every Component. Changing a Prism-owned visual property from here is prohibited.
+
+## Composition
+
+**`exports`** `StackGrid01` — the public runtime names this Block promises
+**`source`** `packages/ui/src/blocks/stack-grid-01/index.tsx` — the file this Block is defined in
+**`dependencies`** `Card, Section` — the public Prism exports this item composes

package/dist/md/blocks/stats-01.md

@@ -0,0 +1,89 @@
+# Stats01
+
+A KPI row with optional directional deltas.
+
+```tsx
+import { Stats01 } from '@nanisoft/prism-ui/blocks/stats-01'
+```
+
+## Overview
+
+Stats01 is a row of key figures. Each stat carries a label, a value, and
+optionally a delta and a hint. The delta renders a direction and a percentage;
+the hint names the period it compares against.
+
+Every number is a prop. The block previously carried invented figures and a
+hardcoded heading, which meant a consumer who installed it shipped fabricated
+metrics into their own dashboard.
+
+## Guidelines
+
+### When to use
+
+Use Stats01 to summarise two to four figures that a reader should compare at a
+glance. It works best when the figures share a unit and a period.
+
+### When not to use
+
+Do not use it for a single figure. One stat in a four-column grid leaves an
+awkward empty row and overstates the number's importance.
+
+Do not use it for figures that need a trend over time. A delta is a comparison
+between two points, not a series; use a chart for a series.
+
+Do not use it when the numbers do not share a period. Mixing "this month" with
+"this quarter" in one row invites a false comparison.
+
+### Best practices
+
+- Give every delta a hint. A percentage with no period is unreadable, because
+  the reader cannot tell what it compares against.
+- Omit `delta` rather than passing `0` when a figure has no meaningful change.
+  A zero delta renders a neutral marker, which is correct only when the value
+  truly held.
+- Keep the label short and the value exact. The reader is scanning, not reading.
+- Use three or four stats. Two fits, one does not.
+
+### Content guidelines
+
+- A label is a noun phrase in sentence case: "Active projects".
+- A hint names the comparison and the period: "vs last month", "vs last
+  quarter".
+- Format the value for the reader: thousands separators, one unit, and no more
+  precision than the source supports.
+
+**The KPI row, with one of each delta direction and one figure with none.**
+
+```tsx
+import { Stats01 } from '@nanisoft/prism-ui/blocks/stats-01'
+
+/** The KPI row, with one of each delta direction and one figure with none. */
+export default function Stats01Demo() {
+  return (
+    <Stats01
+      headingLevel="h3"
+      eyebrow="Preview"
+      title="Section heading"
+      stats={[
+        { label: 'First metric', value: '1,284', delta: 12, hint: 'vs last month' },
+        { label: 'Second metric', value: '47.2%', delta: -3, hint: 'vs last month' },
+        { label: 'Third metric', value: '2.4d', delta: 0, hint: 'vs last quarter' },
+        { label: 'Fourth metric', value: '138' },
+      ]}
+    />
+  )
+}
+```
+
+## Props
+
+**`eyebrow`** `string` · optional · default: —
+**`title`** `string` · optional · default: —
+**`stats`** `Stat[]` · required · default: —
+**`headingLevel`** `HeadingLevel` · optional · default: — — Heading level for the section title. See `HeadingLevel`.
+
+## Composition
+
+**`exports`** `Stats01` — the public runtime names this Block promises
+**`source`** `packages/ui/src/blocks/stats-01/index.tsx` — the file this Block is defined in
+**`dependencies`** `Card, Section` — the public Prism exports this item composes

package/dist/md/blocks/status-ledger-01.md

@@ -0,0 +1,121 @@
+# StatusLedger01
+
+A ledger of things and the state each is in: a name, one of four status tiers and the words for that tier.
+
+```tsx
+import { StatusLedger01 } from '@nanisoft/prism-ui/blocks/status-ledger-01'
+```
+
+## Overview
+
+StatusLedger01 is a ledger of things and the state each is in: a hairline row per
+entry, a mark for the tier, and the words for the state beside the name.
+
+All four NaniSoft sites publish this section, and three of them publish it as a
+ledger of rows while the fourth publishes the same shape as a list of products;
+the ledger appears twice in the fourth site as well, once for use cases and once
+for research directions. Five ledgers across four sites, each one written by hand,
+each one re-deciding the same four things: which tier words to use, how the tier
+is drawn, whether the tier is announced, and whether the row carries a detail
+line or a bullet list.
+
+**The tier is four and the words are the caller's.** The `status` prop takes one
+of four tiers and the `statusLabel` prop takes the words. That split is the whole
+design: the tier is a colour, and colour is not information a reader can act on;
+the words are the information, and the words belong to the product.
+
+The four tiers are `live`, `designed`, `planned` and `direction`. Between them the
+four sites use eight different words for those four states - `live`, `available`
+and `complete` all mean the first; `approved`, `specified` and `designed` all mean
+the second - and that vocabulary is what `statusLabel` is for.
+
+## Guidelines
+
+### When to use
+
+Use StatusLedger01 when a reader needs to know how far along each of several
+things is, and the difference between the states is the point.
+
+Use it when the states are not all the same. A ledger of four rows that are all
+`live` is a list with a column in it, and a plain list says that more plainly.
+
+### When not to use
+
+Do not use it for a list of things that are all available. `NoteGrid01` is for
+that, and a ledger of green dots is a decoration.
+
+Do not use it for a plan with dates. A tier says where a thing stands, not when it
+will move, and a ledger cannot say when.
+
+Do not use it to compare products. A comparison has a row per product and a column
+per fact, and this is the other way round.
+
+### Best practices
+
+- Order the rows by state, most available first, when the reader's question is
+  "what can I use". Order them by importance when it is not.
+- Write `statusLabel` as the sentence you would say out loud. It is the state a
+  screen reader hears, so "Planned" is better than a bare dot and "Available in
+  Q3" is better than "Planned" if that is the truth.
+- The dot is `aria-hidden` on purpose. Nothing in a row depends on a reader being
+  able to see it, and that is the rule to keep if you fork the design.
+- Prefer a `detail` line to a bullet list unless the row really lists things. A
+  row with four bullets and a row with one sentence beside it are hard to scan
+  together.
+
+### Content guidelines
+
+- Keep a name to one or two words. It is the anchor of the row.
+- Do not put the state in the name as well as in the label. "Live capture" beside
+  "Available" says the same thing twice.
+- A row with no detail and no bullets is a valid row, and most rows should be.
+
+**Four rows, one per tier, with the caller's own words for each state.**
+
+```tsx
+import { StatusLedger01 } from '@nanisoft/prism-ui/blocks/status-ledger-01'
+
+/** Four rows, one per tier, with the caller's own words for each state. */
+export default function StatusLedger01Demo() {
+  return (
+    <StatusLedger01
+      headingLevel="h3"
+      eyebrow="Preview"
+      title="What it captures"
+      description="The tiers are the colour; the words beside them are the information."
+      caption="A research direction is named as one. It is not a shipped capability."
+      rows={[
+        {
+          name: 'Access traversal',
+          status: 'live',
+          statusLabel: 'Flagship - available today',
+          detail: 'Every path between a person and a sensitive product.',
+        },
+        {
+          name: 'Containment rehearsal',
+          status: 'designed',
+          statusLabel: 'Specified, not built',
+          bullets: ['Rehearse before you need it.', 'Against the graph you have.'],
+        },
+        { name: 'Privilege hygiene', status: 'planned', statusLabel: 'Planned' },
+        { name: 'Strategy backtesting', status: 'direction', statusLabel: 'Research direction' },
+      ]}
+    />
+  )
+}
+```
+
+## Props
+
+**`eyebrow`** `string` · optional · default: — — Optional label above the section title. See the No-Default-Eyebrow Rule.
+**`title`** `string` · optional · default: — — The section title. Omit it for a ledger composed under its own heading.
+**`description`** `string` · optional · default: — — One or two sentences under the title.
+**`rows`** `readonly StatusRow[]` · required · default: — — The rows, in the order a reader should meet them. Order is the caller's because it is a claim about what matters first, and a ledger that sorted itself would be making that claim on the caller's behalf.
+**`caption`** `string` · optional · default: — — The line under the ledger, for the sentence that qualifies it: what is not here, or where to read more.
+**`headingLevel`** `HeadingLevel` · optional · default: — — Heading level for the section title. See `HeadingLevel`.
+
+## Composition
+
+**`exports`** `StatusLedger01` — the public runtime names this Block promises
+**`source`** `packages/ui/src/blocks/status-ledger-01/index.tsx` — the file this Block is defined in
+**`dependencies`** `Section` — the public Prism exports this item composes

package/dist/md/changelogs/prism-llms.md

@@ -0,0 +1,206 @@
+# @nanisoft/prism-llms
+
+## 0.5.0
+
+### Minor Changes
+
+- 76c8d96: Fourteen items, four catalogue gates, and a Block that publishes its interface
+  
+  **Fourteen items ship.** Three Components (`Prose`, `FactList`, `ProductSwitcher`),
+  nine Blocks (`ProcessRail01`, `StatusLedger01`, `ProductGrid01`, `StackGrid01`,
+  `LogoStrip01`, `NoteGrid01`, `InstrumentPanel01`, `SiteHeader`, `SiteFooter`) and two
+  Pages (`NotFoundPage`, `BlogPostPage`). Every one of them earns its place by the
+  growth rule rather than by taste: a marketing Block when at least three of the four
+  sites compose that section today, a Component when it has one job no existing
+  Component can express. The evidence is in the ticket and in each item's own
+  JSDoc, which names the sites and the line numbers.
+  
+  **The three contested shapes are settled as specified, and the specifications
+  held.** A process rail admits four steps and refuses five, in the type: `steps` is
+  a tuple union, so a five-element array is a compile error and not a fifth column. A
+  status ledger has four tiers rather than five, and the words for a tier are the
+  caller's: the four sites between them use eight words for those four states
+  (`live`, `available` and `complete` are one; `approved`, `specified` and `designed`
+  are one; then `planned`; then `direction`), and the vocabulary is what `statusLabel`
+  is for. A product row's mark is two parts because a filled dot fails contrast on a
+  light card, so the mark is `ProductMark`: a hairline ring in `brand-ink` around a
+  core in the product's own `primary` fill, with the name in the brand ink beside it.
+  
+  **Four gates the catalogue's own rules depend on now exist and are wired into
+  `check` and, because they read only `src/`, into `build`.** `check-item-docs`
+  holds AGENTS.md's claim that a documentation comment is the only path from an Item
+  to its published interface. `check-block-copy` holds DESIGN.md's claim that a
+  Block ships no copy and no sample data. `check-item-category` holds CONTEXT.md's
+  closed set of seven Categories and the sentence that a Block and a Page have none.
+  `check-block-imports` holds the claim that a Block fetches nothing and a Page
+  imports no router and no data client. Each resolves its roots from its own
+  location, fails a root that resolves to nothing, prints its coverage and every
+  exclusion on every run, has no report-only mode, and is proved red by a fixture
+  before it is proved green.
+  
+  **Two of those four gates were red on the tree they were written against, and both
+  findings were real.** `check-item-docs` found seven exported functions whose
+  documentation comment was not attached to the declaration: `CardHeader`,
+  `CardTitle`, `CardDescription`, `CardContent`, `CardFooter`, `SectionHeading` and
+  `Hero01`. A comment three functions above a declaration does not reach the emitted
+  `.d.ts`, so those seven were absent from the corpus. `check-block-copy` found
+  `pricing-01` rendering the word "Popular" on a featured plan that passed no badge:
+  a hardcoded claim every consumer of the Block inherited, published by the corpus as
+  part of the Block's own documentation. The fallback is gone; a featured plan with
+  no badge now renders no badge.
+  
+  **Five additive fields on four shipped items**, each with three of the four
+  consumers passing a value the item could not take, counted per consumer with a
+  file and a line and never per string. `SectionHeading.index`, for the mono ordinal
+  all four sites render above every section head (www `Landing.tsx:49`, atlas
+  `landing.tsx:48`, nexus `Landing.tsx:38`, alphalens `Landing.tsx:66`).
+  `Cta01.secondaryAction`, for the pair of actions all four closing bands render
+  (www `Landing.tsx:186`, atlas `landing.tsx:243`, nexus `Landing.tsx:221`,
+  alphalens `Landing.tsx:285`). `Cta01.note`, for the footnote three of the four
+  render under it (atlas `landing.tsx:250`, nexus `Landing.tsx:228`, alphalens
+  `Landing.tsx:292`). `FeatureGrid01.numbered`, for the ordinal all four render on
+  every card (www `Landing.tsx:166`, atlas `landing.tsx:116`, nexus `Landing.tsx:132`,
+  alphalens `Landing.tsx:142`). `Hero01.align`, for the left-aligned hero three of
+  the four compose (atlas `landing.tsx:69`, nexus `Landing.tsx:63`, alphalens
+  `Landing.tsx:87`). All five are additive: nothing changed shape and nothing was
+  removed.
+  
+  **A Block and a Page publish both an interface section and a composition section.**
+  `packages/llms` read the extractor's output for a Block and threw the interface half
+  away, so the tool told an agent a Block had no own props. The extractor reads a
+  named props type off an emitted declaration whether that declaration belongs to a
+  Component or to a Block, so both sections are now built and both are assembled into
+  the mirror file, `llms-full.txt` and the Store's `doc`.
+  
+  The Store now carries both fields for every kind, and `get_item_props` prints
+  both when it has both. The sentence "a Block has no own props" is gone from the
+  tool as well as from the published document. It was the one place the two
+  sections were still exclusive, because that tool branched on `item.props` and
+  fell back to the composition section, so a Block was answered with its
+  composition and a denial of the interface it publishes. The test asserts the
+  sentence's absence, so a refactor that restores it fails even if the composition
+  is still printed, and a second test covers the one-present case so the
+  both-present branch cannot swallow it.
+  
+  **Four accessible names became required props** on `SiteHeader`, `LogoStrip01`,
+  `NotFoundPage` and `BlogPostPage`, and a Block that ships no copy ships no
+  reader-facing copy either. `navLabel`, `productsLabel`, `label`, `linksLabel` and
+  `trailLabel` are words a screen reader reads out, and no Block should be choosing
+  them for a consumer whose site calls its own landmarks something else. This is the
+  one breaking change in the release, and it is on four new Blocks and two new Pages
+  plus one new required prop on `SiteHeader`, all of which are new in the same
+  release, so no existing call site changes.
+  
+  **`ProductSwitcher.label` has no default** for the same reason: a consumer whose set
+  is not a set of products should pass its own word rather than accept a claim about
+  what the set is.
+
+### Patch Changes
+
+- 4832359: Build the corpus after the changelog routes are copied, and declare what it reads
+  
+  The corpus asserts that every published package shipping a changelog has a route
+  in the site's content tree, and those routes are written by a copy step that
+  belongs to the site package. The copy ran after this package was built, so on a
+  cold machine the build failed with a message that read like a changelog file had
+  been deleted, and a warm machine never saw the failure at all.
+  
+  The copy is now the task `@nanisoft/site#copy-changelogs`, which this build
+  depends on in the task graph, and this build declares the content tree, the Item
+  documentation tree, the two site script modules the builder imports, the
+  workspace globs, the published manifests and the changelogs as its inputs, so a
+  change to any of them rebuilds the corpus instead of replaying a cached one.
+  
+  The assertion is unchanged and still fails a published package the site does not
+  publish, which is how a changelog path the corpus advertised while the site
+  returned 404 for it was found. Its message now says which of the two causes it
+  is. No corpus byte changes: the emitted corpus is the same.
+
+## 0.2.0
+
+### Minor Changes
+
+- c0cc0a9: Publish seven Sections, and keep every published URL resolving
+  
+  `STORE_SECTIONS` is `overview`, `foundation`, `content`, `changelogs` where it
+  was `docs`, `foundations`, `content`, `changelogs`, and `STORE_SECTION_TITLES`
+  carries the Section's own name beside its directory. The two are a pair for a
+  reason: the directory is the route a page is addressed by and `get_page` matches
+  on it, and the name is what `llms.txt` groups pages under and what `list_pages`
+  counts. A Section renamed without its label renamed would be advertised under two
+  names in two artifacts, and a page whose `section` no longer names a live
+  directory is a page no tool can reach.
+  
+  The reading order of the prose Sections is the site's: Overview, then Foundation,
+  then Content, then the catalogue, then the Changelogs. The corpus is regenerated
+  at build, so `llms.txt`, `llms-full.txt`, `data.json` and every mirror under `md/`
+  advertise the new routes, and the site Worker answers each old route with a
+  permanent redirect generated from the same manifest. An agent holding a cached
+  `llms.txt` from before this release resolves every URL it names and is told
+  nothing about the move.
+  
+  Nothing in the item surface moves. The forty-two catalogue routes are the same
+  forty-two addresses, their mirrors are byte-identical, and the nine tools keep
+  their names and their positions; `list_pages` and `get_page` are unchanged apart
+  from the Section names they group and describe, which is a parameter on the
+  existing tools and not a rename of any of them.
+- b1125a0: Publish the Changelogs Section, and put the changelogs in the agent surface
+  
+  There was no Changelogs Section, so the only record of a change in a published
+  package was a file inside its tarball. A reader now has one route per published
+  package and an agent can ask for it. Both halves land together, so a Section never
+  exists without being in the Corpus.
+  
+  The per-package pages are byte-for-byte copies of each published package's own
+  `CHANGELOG.md`, written by a copy step inside the build the site already runs.
+  That is the whole reason for the shape: a hand-maintained copy of a changelog
+  drifts from what was published while continuing to look correct, and it is a third
+  place to remember alongside the changeset and the JSDoc. The published packages
+  are discovered from the workspace, so publishing a package is what adds a route,
+  and a package that ships a changelog and no route fails the build in three
+  places. The reference design system this is modelled on has reader-facing
+  changelog pages and no such gate, which is how every one of them can be deleted
+  and leave its continuous integration green.
+  
+  `STORE_SECTIONS` gains `changelogs`, so `llms.txt`, `llms-full.txt` and the
+  Markdown mirror carry a Changelogs group, and the content walk reads the second
+  extension the Section needs: a copied changelog is plain Markdown, and a walk
+  filtered to `.mdx` would have left the whole Section out of the agent surface
+  with a green build. The walk already recursed, so a page nested inside a Section
+  reaches the Corpus the same way it did before.
+  
+  `PrismDocsStore` gains a required `changelogs` field carrying each package's
+  bytes, its route and its version entries, and the MCP server gains one read-only
+  tool, `get_changelog(package, version?)`, registered last. The eight existing
+  tools keep their names and their positions: a Section joining the Corpus is a
+  parameter on `list_pages` and `get_page`, which now read the Sections from the
+  Store rather than from a list of the three prose Sections, and not a rename of
+  anything. `get_changelog` returns the package's own file, because a generated
+  summary would drift the moment a release was published, and a breaking change in
+  a published package is exactly what a consuming agent has to be able to find.
+
+### Patch Changes
+
+- cbf442f: Make the corpus walk the content tree, and make a missing Section fail
+  
+  The generator read one directory per Section and filtered it to `.mdx`, so a page
+  one folder deeper was absent from `llms.txt`, from `llms-full.txt`, from the
+  `PrismDocsStore` and from every read-only MCP tool, with a green build. The walk
+  now recurses, and a page's route, its `slug` and its Markdown mirror all come
+  from where the page sits in the tree, so nesting content publishes a page
+  instead of losing it.
+  
+  The same file guarded the Section loop with `if (!existsSync(dir)) continue`, so a
+  Section that was declared and not on disk, which is what renaming one does, was
+  skipped silently and deleted from every agent surface. It now throws.
+  
+  `llms.txt`, `llms-full.txt`, `data.json` and `md/**` are byte-for-byte unchanged
+  for the current flat tree.
+
+## 0.1.0
+
+The first versioned line of the rebuilt Prism agent corpus. One build-fresh
+`dist/` carries `llms.txt`, `llms-full.txt`, `prism-skill.md`, the per-item
+Markdown mirror and `data.json`, the `PrismDocsStore` projection.
+
+Changesets are appended above this entry for every published change.

package/dist/md/changelogs/prism-mcp-server.md

@@ -0,0 +1,88 @@
+# @nanisoft/prism-mcp-server
+
+## 0.4.0
+
+### Patch Changes
+
+- Updated dependencies [4832359]
+- Updated dependencies [76c8d96]
+  - @nanisoft/prism-llms@0.3.0
+
+## 0.2.0
+
+### Minor Changes
+
+- c0cc0a9: Publish seven Sections, and keep every published URL resolving
+  
+  `STORE_SECTIONS` is `overview`, `foundation`, `content`, `changelogs` where it
+  was `docs`, `foundations`, `content`, `changelogs`, and `STORE_SECTION_TITLES`
+  carries the Section's own name beside its directory. The two are a pair for a
+  reason: the directory is the route a page is addressed by and `get_page` matches
+  on it, and the name is what `llms.txt` groups pages under and what `list_pages`
+  counts. A Section renamed without its label renamed would be advertised under two
+  names in two artifacts, and a page whose `section` no longer names a live
+  directory is a page no tool can reach.
+  
+  The reading order of the prose Sections is the site's: Overview, then Foundation,
+  then Content, then the catalogue, then the Changelogs. The corpus is regenerated
+  at build, so `llms.txt`, `llms-full.txt`, `data.json` and every mirror under `md/`
+  advertise the new routes, and the site Worker answers each old route with a
+  permanent redirect generated from the same manifest. An agent holding a cached
+  `llms.txt` from before this release resolves every URL it names and is told
+  nothing about the move.
+  
+  Nothing in the item surface moves. The forty-two catalogue routes are the same
+  forty-two addresses, their mirrors are byte-identical, and the nine tools keep
+  their names and their positions; `list_pages` and `get_page` are unchanged apart
+  from the Section names they group and describe, which is a parameter on the
+  existing tools and not a rename of any of them.
+- b1125a0: Publish the Changelogs Section, and put the changelogs in the agent surface
+  
+  There was no Changelogs Section, so the only record of a change in a published
+  package was a file inside its tarball. A reader now has one route per published
+  package and an agent can ask for it. Both halves land together, so a Section never
+  exists without being in the Corpus.
+  
+  The per-package pages are byte-for-byte copies of each published package's own
+  `CHANGELOG.md`, written by a copy step inside the build the site already runs.
+  That is the whole reason for the shape: a hand-maintained copy of a changelog
+  drifts from what was published while continuing to look correct, and it is a third
+  place to remember alongside the changeset and the JSDoc. The published packages
+  are discovered from the workspace, so publishing a package is what adds a route,
+  and a package that ships a changelog and no route fails the build in three
+  places. The reference design system this is modelled on has reader-facing
+  changelog pages and no such gate, which is how every one of them can be deleted
+  and leave its continuous integration green.
+  
+  `STORE_SECTIONS` gains `changelogs`, so `llms.txt`, `llms-full.txt` and the
+  Markdown mirror carry a Changelogs group, and the content walk reads the second
+  extension the Section needs: a copied changelog is plain Markdown, and a walk
+  filtered to `.mdx` would have left the whole Section out of the agent surface
+  with a green build. The walk already recursed, so a page nested inside a Section
+  reaches the Corpus the same way it did before.
+  
+  `PrismDocsStore` gains a required `changelogs` field carrying each package's
+  bytes, its route and its version entries, and the MCP server gains one read-only
+  tool, `get_changelog(package, version?)`, registered last. The eight existing
+  tools keep their names and their positions: a Section joining the Corpus is a
+  parameter on `list_pages` and `get_page`, which now read the Sections from the
+  Store rather than from a list of the three prose Sections, and not a rename of
+  anything. `get_changelog` returns the package's own file, because a generated
+  summary would drift the moment a release was published, and a breaking change in
+  a published package is exactly what a consuming agent has to be able to find.
+
+### Patch Changes
+
+- Updated dependencies [cbf442f]
+- Updated dependencies [c0cc0a9]
+- Updated dependencies [b1125a0]
+  - @nanisoft/prism-llms@0.2.0
+
+## 0.1.0
+
+The first versioned line of the rebuilt Prism MCP surface. The package is
+transport-free: `createPrismMcpServer(store, options)` returns an `McpServer`
+that the site Worker connects to the Agents SDK at `/mcp`. Eight read-only
+retrieval tools answer over the bundled `PrismDocsStore`.
+
+Changesets are appended above this entry for every published change.