Pagination added and search and filtering moved to backend
Build LinkLog Development Image / development-image (push) Successful in 22s
Build LinkLog Development Image / development-image (push) Successful in 22s
This commit is contained in:
@@ -0,0 +1,27 @@
|
||||
---
|
||||
name: changelog-maintenance
|
||||
description: "Use when: completing LinkLog work that changes user-facing behavior (features, fixes, UI/UX, configuration, API responses). Update CHANGELOG.MD's current unreleased version section, and bump frontend/version.json when the user explicitly requests a version bump or release."
|
||||
---
|
||||
|
||||
# LinkLog Changelog Maintenance
|
||||
|
||||
## Purpose
|
||||
|
||||
`CHANGELOG.MD` is LinkLog's user-facing history of releases. Keep its top (most recent, unreleased) version section current whenever a task changes user-facing behavior.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Complete the user's requested work and its relevant validation first.
|
||||
2. Decide if the change is changelog-worthy (see Scope below). Skip internal-only changes.
|
||||
3. Open `CHANGELOG.MD` and find the topmost `## Version vX.Y.Z` section — this is the current unreleased version being accumulated. Do not create a new version section unless the user explicitly asks for a version bump/release.
|
||||
4. Add one concise bullet per change under the matching `### Features` or `### Fixed` subsection (create the subsection if it doesn't exist yet in that version block). Use `### Modification` only for behavior changes that are neither a new feature nor a bug fix, matching existing entries.
|
||||
5. Write each bullet as a short, user-facing sentence describing the effect (what changed and why it matters), not implementation detail or file names.
|
||||
6. Do not edit, reorder, or remove bullets from older `## Version` sections. Only append to the current unreleased section.
|
||||
7. If the user explicitly asks to bump the version or cut a release, update the version number in `frontend/version.json` (valid JSON, e.g. `{"version": "0.3.1"}`) to match the `## Version vX.Y.Z` heading, and start a new top section for subsequent changes.
|
||||
8. Before finalizing, re-read `CHANGELOG.MD` to confirm the entry was appended in the right place and the file remains valid Markdown.
|
||||
|
||||
## Scope
|
||||
|
||||
Changelog-worthy: new features, bug fixes, UI/UX changes, configuration options, API/behavior changes visible to users or operators.
|
||||
|
||||
Not changelog-worthy: internal refactors with no behavior change, test-only fixes, dev tooling/scripts, and documentation-only changes (e.g. `VIBE/`, `DATABASE.md`, skill files) — unless the user asks otherwise.
|
||||
Reference in New Issue
Block a user