Application changelog

The application changelog at /changelog is the public-facing release-notes surface for buyers. Authoring sits at /admin/changelog (super_admin only).

Format

Each entry is one row keyed by an immutable version (semver: v1.4.0). Entries follow the Keep a Changelog convention — markdown with sections under ## Added / ## Changed / ## Fixed / ## Removed / ## Security. The public renderer supports headings, bullet lists, **bold**, and `code` spans; everything else passes through as plain text.

Status lifecycle

Status	What it does
draft	Default on create. Invisible to buyers; the public /changelog page filters drafts out.
published	Visible to buyers. The entry's version becomes immutable — buyers may have linked to /changelog#v1.4.0 and silently changing what that anchor refers to would rewrite history. To renumber, archive the entry first and create a new one.
archived	Hidden from the public listing but kept in the table so old buyer linkbacks still resolve. Use this instead of hard-deleting.

JSON feed

/changelog.json serves the same published entries as machine-readable JSON, capped at the latest 100. Buyers can scrape it for embedding "what's new" widgets in their own dashboards or subscribing via a Make/Zapier polling trigger.

{
  "brand": "Pitchbar",
  "entries": [
    {
      "version": "v1.4.0",
      "released_at": "2026-05-09T00:00:00+00:00",
      "title": "Workflow visual editor + Phase 2 step types",
      "body": "## Added\n- React Flow canvas\n…"
    }
  ]
}

What's-new banner

Authenticated workspace members see a slim "What's new in vX.Y.Z" banner across the top of the admin shell whenever a published entry is newer than the user's users.last_changelog_seen_at timestamp. Dismissing the banner POSTs to /changelog/seen and stamps the timestamp; the banner stays hidden until the next entry lands. Super-admins don't see the banner — they author the entries themselves.

CLI

php artisan changelog:add drops an entry from the terminal — useful for committing release notes alongside the code that ships them.

php artisan changelog:add v1.4.0 \
  --title="Workflow visual editor" \
  --status=published \
  --body="$(cat <<'EOT'
## Added
- React Flow canvas at /app/workflows/{id}/canvas
- Branch / tag_lead / webhook step types

## Fixed
- Mobile homepage hero overflow on viewports under 480px
EOT
)"

Idempotent on version — re-running with the same semver leaves the existing row untouched. To edit a published entry, use the admin form at /admin/changelog/{id}/edit.

Persistence

Changelog entries live as a single JSON file at storage/app/private/changelog-entries.json — same pattern as the internal Kanban board. Storage is intentionally NOT a database table, so php artisan migrate:fresh during development never wipes release notes.

On every read, the store auto-seeds itself from source markdown files at database/changelog-entries/v*.md. New versions on disk are inserted; existing entries are never overwritten (admin edits in the UI are the source of truth post- bootstrap). This gives a "ship the source in git, sync to disk on first request" workflow with zero manual steps — deploying the new code, hitting /changelog once, the entries appear.

Source markdown shape

---
version: v1.1.0
title: Visual workflow editor, customizable lead form, and widget polish
released_at: 2026-05-09
---

## New features

**Visual workflow editor.** Build branching chat flows on a
drag-and-drop canvas...

## Improvements

...

## Fixes

...

Three frontmatter fields are required: version, title, and released_at. Body is plain markdown rendered by the public changelog page.

Disabling the bootstrap

Set changelog.bootstrap_dir to an empty string in your config or environment overlay. Useful when you want an empty changelog and want to author entries from scratch via the admin UI.