docs: add Changelog and Blog tabs powered by Mintlify Update component

[prasanna-anchorage]

Summary

• Adds two new top-level Mintlify tabs to the docs site, both built on Mintlify's native <Update> primitive so we get subscribable RSS without any custom tooling.
• Changelog (/changelog) — curated, per-meaningful-release timeline. Backfilled with three entries covering the Solana preset wave, HTTP-gateway chain_metadata + content digests (PR feat: forward chain_metadata and expose digests in HTTP gateway #287), and surfpool mainnet-fork fuzz integration (PR test: surfpool mainnet-fork integration for built-in IDL fuzz path #202).
• Blog (/blog) — stub list linking to full essay pages. Launches with Composable by design: how Solana presets stack — a concept piece that ties the recent preset wave to the build-time preset registry (visualsign-solana/build.rs) and the InstructionVisualizer / SolanaIntegrationConfig composition seams. Composability is the through-line.
• Free RSS feeds at /changelog/rss.xml and /blog/rss.xml, courtesy of Mintlify's built-in <Update>-driven feed generation. No custom generator script, no CI diff check.
• Adds docs/changelog/_drafts/ with a README documenting the in-PR fragment workflow: contributors drop drafts close to the change, maintainers batch them into <Update> blocks at curation time.

Composability emphasis

The blog essay walks through how 14+ recent Solana protocols shipped without touching any existing decoder or the core parser: each new directory under src/chain_parsers/visualsign-solana/src/presets/ is auto-registered by build.rs, dispatch is via visualize_with_any() matching on program id, and unknown_program always sorts last as the catch-all. The seams are the product — that's the headline.

Test plan

• Mintlify auto-deploy preview renders /changelog with three <Update> blocks stacked, tag chips visible.
• Mintlify auto-deploy preview renders /blog with one <Update> stub linking to the full essay page.
• /blog/2026-05-13-composable-solana-presets renders the full essay with frontmatter title and description applied.
• /changelog/rss.xml returns valid RSS 2.0 with three items and <category> elements per tag.
• /blog/rss.xml returns valid RSS 2.0 with one item.
• No broken internal links (manual review of /chains/solana, /changelog, /blog/... cross-links).
• Voice guide adherence: sentence case, em-dashes, second-person, no Anchorage standalone, no ≥/→ — all confirmed via grep at authoring time.

🤖 Generated with Claude Code

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
visualsign-parser	🟢 Ready	View Preview	May 13, 2026, 4:55 PM

[Copilot]

Pull request overview

Adds Mintlify-powered Changelog and Blog sections to the docs site, using <Update> entries for release notes, blog stubs, and RSS feed generation.

Changes:

• Adds Changelog and Blog tabs to docs.json.
• Adds a changelog page with three release entries.
• Adds a blog index, full Solana presets essay, and changelog draft workflow docs.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
docs/docs.json	Adds top-level Changelog and Blog navigation tabs.
docs/changelog/_drafts/README.md	Documents the draft fragment workflow for changelog entries.
docs/changelog.mdx	Adds the new Update-based changelog page.
docs/blog.mdx	Adds the new Update-based blog landing page.
docs/blog/2026-05-13-composable-solana-presets.mdx	Adds the full Solana presets composability essay.

Comments suppressed due to low confidence (12)

docs/blog/2026-05-13-composable-solana-presets.mdx:49

• This overstates the current Ethereum behavior. The only production call path I found for LayeredRegistry<ContractRegistry> ignores request options and returns LayeredRegistry::new(...), with wallet-provided token overrides left as a TODO in src/chain_parsers/visualsign-ethereum/src/lib.rs:191-208; with_request is only used in examples/tests. Please rephrase this as a planned capability or document the behavior that exists today.

If you're **integrating VisualSign into a wallet**, composability shows up at the data layer too. The Ethereum side uses `LayeredRegistry<T>` to compose wallet-provided overrides on top of compiled-in defaults — wallets can ship their own opinions about token metadata without forking VisualSign. The Solana side currently composes through fixed IDL + preset layers; wallet-side overlays are the natural next step.

docs/blog/2026-05-13-composable-solana-presets.mdx:53

• This overstates the Surfpool setup as not needing a live cluster. The current test utility always configures an upstream mainnet RPC URL by default and the Surfpool tests are documented as requiring network access, so this should say the tests avoid executing directly on a live cluster while still needing live RPC access for the fork.

If you're **writing tests**, surfpool (PR #202) composes real Solana mainnet state into the local harness. Tests run against forked chain data, which catches drift between IDL assumptions and on-chain reality without a live cluster.

docs/blog.mdx:9

• The stub names layered registries as one of the three composition primitives, but the full essay's "three pieces" are the built-in IDL parser, protocol-specific preset overlays, and the build-time registry. This mismatch makes the teaser inaccurate; it should refer to the build-time registry unless the essay is reorganized.

  Adding a new protocol to VisualSign rarely touches existing code. The recent Solana preset wave is a useful proof point: 14 protocols shipped without changes to existing decoders or the core parser. This post walks through the three composition primitives — the built-in IDL parser, protocol-specific preset overlays, and layered registries — and why each preset is a pure addition rather than a modification. [Read the full post](/blog/2026-05-13-composable-solana-presets).

docs/blog/2026-05-13-composable-solana-presets.mdx:34

• available_visualizers() is described as a generated slice, but the generated function currently returns a Vec<Box<dyn InstructionVisualizer>> (build.rs formats pub fn available_visualizers() -> Vec<...>). Please use Vec, list, or collection here to avoid misleading readers who look for a slice API.

`available_visualizers()` is the generated slice. `unknown_program` always sorts last, so it catches anything no specific preset claimed. A preset registered for Jupiter's program id has zero knowledge of MetaDAO's preset, and vice versa. The dispatch lookup is the only coupling.

docs/blog/2026-05-13-composable-solana-presets.mdx:18

• This is not quite accurate for new preset contributors: adding a preset directory is not the only registration step because src/chain_parsers/visualsign-solana/src/presets/mod.rs must also get a pub mod {snake_name}; entry (the solana-add-idl skill documents this as Step 4). build.rs discovers the visualizer for the generated registry, but Rust still needs the module declared.

3. **A build-time registry.** `build.rs` scans `src/presets/` and emits a generated `available_visualizers()` function — one `Box::new(<Dir>::<Pascal>Visualizer)` per directory. The build comment in the script puts the design intent plainly: "this should allow us to functionally compose instructions at the time of display." There is no central registration site to edit. Adding a directory is the registration.

docs/blog/2026-05-13-composable-solana-presets.mdx:43

• This repeats the same registration inaccuracy: preset PRs do need to touch the shared src/chain_parsers/visualsign-solana/src/presets/mod.rs module list so the new directory is compiled, even though build.rs handles the generated visualizer registry. Please avoid saying nothing outside the preset directory changes.

Nothing else moved. Reviewers read each preset PR in isolation. CI sees no ripple.

docs/blog/2026-05-13-composable-solana-presets.mdx:57

• The claim that there is "no list to drift out of sync" is contradicted by the required pub mod ... list in src/chain_parsers/visualsign-solana/src/presets/mod.rs, which must be updated for each new preset. The generated visualizer registry reduces one source of drift, but the module list still exists.

"Composable by design" is a phrase. The work is in keeping the seams clean as surface area grows. Build-time discovery of presets means there's no list to drift out of sync. Field builders mean two contributors emitting the same content produce identical bytes. A typed IDL view between the raw instruction and the preset means presets only see well-shaped input.

docs/blog/2026-05-13-composable-solana-presets.mdx:47

• This contributor-facing checklist omits the shared module registration step. The solana-add-idl skill's Step 4 requires adding pub mod {snake_name}; to src/chain_parsers/visualsign-solana/src/presets/mod.rs, so describing the change as only one new directory will leave readers with an incomplete process.

If you're **adding a new Solana protocol**, the design pushes you toward a particular shape: one IDL, one visualizer, one config, a handful of fixtures, one new directory. The same shape your reviewer expects, the same shape we expect from ourselves. The `solana-add-idl` skill scaffolds this for you when the protocol exposes an on-chain IDL.

docs/blog.mdx:9

• Calling each preset a "pure addition rather than a modification" is misleading because adding a Solana preset currently also modifies the shared src/chain_parsers/visualsign-solana/src/presets/mod.rs module list. The statement should distinguish generated registry discovery from the still-manual Rust module declaration.

  Adding a new protocol to VisualSign rarely touches existing code. The recent Solana preset wave is a useful proof point: 14 protocols shipped without changes to existing decoders or the core parser. This post walks through the three composition primitives — the built-in IDL parser, protocol-specific preset overlays, and layered registries — and why each preset is a pure addition rather than a modification. [Read the full post](/blog/2026-05-13-composable-solana-presets).

docs/blog/2026-05-13-composable-solana-presets.mdx:16

• This does not match the current Solana preset interface. VisualizerContext passes raw Instruction data plus the IDL registry, and presets such as jupiter_borrow call parse_instruction_with_idl(&instruction.data, ...) and inspect discriminators themselves before building fields; they are not handed a precomputed typed IDL view by the core layer. Please rephrase the architecture so contributors do not expect a typed view to be provided automatically.

1. **A built-in IDL parser.** Any Anchor-style program with an IDL gets a typed view of each instruction — discriminator, account list, argument values — produced generically from the IDL alone. This is the `src/idl/` module. It does not know about Jupiter or Kamino.

2. **Protocol-specific preset overlays.** A preset is a small unit that says "for *this* program id, take the typed view and produce these human-readable fields." Presets implement `InstructionVisualizer` and declare which program id they handle via `SolanaIntegrationConfig`. They never parse bytes; they consume the IDL view and call field builders (`create_text_field`, `create_amount_field`, `create_raw_data_field`) to shape output. Each preset lives in its own directory.

docs/blog/2026-05-13-composable-solana-presets.mdx:57

• The final sentence is inaccurate with the current API: presets receive VisualizerContext with raw Solana Instruction data and are responsible for invoking the IDL parser/fallback handling, so they do not "only see well-shaped input." This should be softened or updated to describe the actual raw-instruction-plus-IDL-registry boundary.

"Composable by design" is a phrase. The work is in keeping the seams clean as surface area grows. Build-time discovery of presets means there's no list to drift out of sync. Field builders mean two contributors emitting the same content produce identical bytes. A typed IDL view between the raw instruction and the preset means presets only see well-shaped input.

docs/blog/2026-05-13-composable-solana-presets.mdx:18

• This is presented as a direct quote from build.rs, but the current comment does not match it exactly (allow use ... at the time of display too). Either quote the source verbatim or paraphrase without quotation marks.

3. **A build-time registry.** `build.rs` scans `src/presets/` and emits a generated `available_visualizers()` function — one `Box::new(<Dir>::<Pascal>Visualizer)` per directory. The build comment in the script puts the design intent plainly: "this should allow us to functionally compose instructions at the time of display." There is no central registration site to edit. Adding a directory is the registration.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.