CHANGELOG TEMPLATE // BOT INTERFACE SPEC#

> THIS PAGE IS NOT A CHANGELOG. > THIS PAGE IS THE STENCIL THE BOT USES TO MAKE ONE.

This page defines the exact structure scripts/apply-changelog.js builds whenever the Discord bot fires a changelog update. Each collection's release is a small clickable card; clicking it opens a popup (a native <dialog>) with the full changes, instead of a long scrolling page. It's a reference for whoever maintains the bot integration — not a page end users need to read.

Payload fields#

Card + popup markup#

Each entry is a <button> (the card) immediately followed by its matching <dialog> (the popup), sharing an id via data-pt-changelog-open="…" / id="…". Both need markdown="1" on themselves, not just the innermost content div — md_in_html treats an entire subtree as opaque raw HTML the moment it hits any ancestor without that attribute, however deep the real markdown="1" div sits.

<button type="button" class="pt-changelog-card" data-pt-changelog-open="{{ dialog_id }}">
<img class="pt-changelog-card-thumb" src="assets/{{ thumbnail_file }}" alt="">
<span class="pt-changelog-card-body">
<span class="pt-changelog-card-version">{{ version }}</span>
<span class="pt-changelog-card-date">{{ date }} · CP2077 {{ game_version }}</span>
<span class="pt-changelog-card-chips">{{ chips }}</span>
</span>
</button>

<dialog class="pt-changelog-modal" id="{{ dialog_id }}" markdown="1">
<div class="pt-changelog-modal-inner" markdown="1">

<button type="button" class="pt-changelog-modal-close" data-pt-changelog-close aria-label="Close changelog">×</button>

## {{ version }}

{{ chips }}

`{{ date }}` · Game Version `{{ game_version }}` · Posted by **{{ author }}** · Synced from `{{ source_channel }}`

### Added {: .pt-changelog-h-added }

{{ added_items }}

### Updated

{{ updated_items }}

### Removed {: .pt-changelog-h-removed }

{{ removed_items }}

</div>
</dialog>

• {{ dialog_id }} — on changelog/index.md this is changelog-current-{{ collection_slug }} (one fixed, unique id per tracked collection). On changelog/archive.md, where many old releases from every collection coexist, it's changelog-{{ slugified version }} instead (e.g. changelog-v4-3-0), with a -2, -3, ... suffix added if that id's already taken (a collection re-posting an identical version string, most likely while testing, would otherwise collide with an already-archived entry).
• {{ thumbnail_file }} — looked up from collection_slug via the COLLECTION_IMAGES map at the top of apply-changelog.js. A slug with no entry there just gets a card with no image — nothing breaks. To add a new collection's thumbnail: drop a .webp into docs/changelog/assets/ and add one line to that map.
• {{ chips }} — one <span class="pt-chip pt-chip--{added|updated|removed}">…</span> per non-empty category, nothing for empty ones.
• The {: .pt-changelog-h-added } / {: .pt-changelog-h-removed } bits are attr_list syntax — that's what lets stylesheets/changelog.css colour those two headings green/red. "Updated" needs no class — <h3> is already yellow site-wide.
• Omit a whole ### Heading {{ items }} block entirely for any empty category — don't post an empty section or its chip.

Where new entries go#

changelog/index.md — each tracked collection has its own collapsible section (<details class="pt-changelog-collection" open>), and inside that section its one "current" card is wrapped in a marker pair keyed by slug:

<!-- CHANGELOG:CURRENT:START -->

<details class="pt-changelog-collection" open markdown="1" data-collection-slug="{{ collection_slug }}">
<summary>{{ collection display name }}</summary>
<div class="pt-changelog-cards" markdown="1">

<!-- CHANGELOG:CURRENT:ENTRY:{{ collection_slug }}:START -->
  ...card + dialog for this one collection...
<!-- CHANGELOG:CURRENT:ENTRY:{{ collection_slug }}:END -->

</div>
</details>

  ...one more <details> section per other tracked collection...

<!-- CHANGELOG:CURRENT:END -->

apply-changelog.js only ever replaces the one ENTRY:{{ collection_slug }} block matching the incoming payload — every other collection's <details> section (and its entry) is left byte-for-byte untouched. If no entry exists yet for that slug, a whole new <details> section is built and inserted at the top of the list instead. The display name comes from the COLLECTION_NAMES map at the top of apply-changelog.js (falls back to the raw slug if a collection isn't listed there).

changelog/archive.md — mirrors the same pattern: each collection gets its own <details class="pt-changelog-collection"> holding only that collection's past releases, newest first, inserted right after its own marker comment (which stays put for next time):

<!-- CHANGELOG:ENTRIES:START -->

<details class="pt-changelog-collection" open markdown="1" data-collection-slug="{{ collection_slug }}">
<summary>{{ collection display name }}</summary>
<div class="pt-changelog-cards" markdown="1">

<!-- CHANGELOG:ARCHIVE:{{ collection_slug }}:PREPEND_HERE -->
  ...new entry for this collection gets inserted right here...
  ...older entries for this same collection...

</div>
</details>

  ...one more <details> section per other collection with archived history...

<!-- CHANGELOG:ENTRIES:END -->

The first time a collection's release ever gets archived, its <details> section (with its own PREPEND_HERE marker) is created and added to the top of the list — after that, every later archive for that same collection just prepends inside its existing section.