feat: journal - Implement accessible journal filtering #366

Outcome

Turn decorative journal categories into functioning accessible controls.

Verified context

JournalPage.tsx uses spans without filter handlers; current labels do not establish actual taxonomy coverage.

Scope

Reconcile displayed values against approved entry metadata and filter the published collection.

Acceptance criteria

• All supported filters return correct results from the same eligible collection.
• Keyboard interaction and selected state are exposed.
• Empty results and reset-to-All behave intentionally.
• Tests cover filtering and detail navigation without implying editorial completion.

Boundaries and sources

Creation defines work only; it does not start implementation. Preserve unrelated code, protected assets, editorial wording and existing records. Do not fabricate content, identity, media, manuscript chapters, dates or engagement data. Use approved repository-native authoring, validation, preview and publication decisions; do not provision an external CMS or database. Existing editorial verification remains with its current issues. All acceptance criteria remain unchecked until evidenced.

Repository evidence was inspected on develop at 4ecdb26d9655a48bf000a7c89da2f70383edce87. Recheck before implementation; no build or browser tests were run for this draft. Follow repository instructions and applicable Spec Kit requirements. Paths below refer to this repository.

Sources: repository instructions, application, editorial content.

Branch instructions

• Repository: lightspeedwp/ThisOneTimeOnAcidCom
• Proposed branch: feat/journal-category-filtering
• Base: develop
• Naming policy: local guide, validator, organisation strategy.
• Pull request template: Organisation .github/PULL_REQUEST_TEMPLATE/pr_feature.md, per inspected local routing; recheck before opening a PR.
• Constraints: Preserve unrelated changes; do not force-push, merge or deploy. Complete applicable Spec Kit requirements before implementation.
• Conflicts or missing evidence: Proposed branch, not an existing branch; collision freedom is unverified. Recheck current branch routing and open governance changes, including PR automation: repo-governance - Add governance automation and validation #346. Older instructions claim branch rules are absent; the inspected local guide and executable validator establish the current convention. This draft creates no branch or pull request.

Branch instructions — verification addendum

For branch-existence and PR-template verification only, this addendum supersedes the earlier Branch instructions. Existing outcomes, scope, acceptance criteria and other constraints remain unchanged.

• Repository: lightspeedwp/ThisOneTimeOnAcidCom
• Implementing scope: accessible filtering of the eligible journal collection; not loader/schema or source-rendering completion.
• Branch state: proposed new branch; existing proposal feat/journal-category-filtering, not found remotely at review.
• Base: develop.
• Naming evidence: local naming guide and validator at develop revision 4ecdb26d9655a48bf000a7c89da2f70383edce87; feat fits adding functioning controls. Recheck before implementation.
• Existing work: no journal-specific open PR found. Coordinate shared archive-page changes with rendering work; do not reuse the governance branch.
• PR template: the shared organisation feature template is the current workflow suggestion only. Automatic branch-based selection, named-template loading and default-template inheritance remain unverified. Read the matching shared template when preparing the PR and use its sections; do not create local template files, modify shared locked templates or assume routing comments load template content.
• Parent context: coordination only; omit parent identifiers from reusable branch/PR text pending association verification. Never use the parent as a native development or closing target.
• Allowed closing targets: none currently; verify this issue’s entire filtering outcome and association effects before proposing closing syntax.
• Dependencies: approved metadata/publication contract, source-backed archive, filter taxonomy, UI-data module and applicable Spec Kit completion.
• Constraints: preserve unrelated changes, approved taxonomy and protected assets. No force-push, merge or deployment.

Expected file changes

Provisional plan; existing paths checked at develop revision 4ecdb26d9655a48bf000a7c89da2f70383edce87.

Filter labels and recovery copy must use src/app/data/mock/; the exact module remains unresolved. Do not invent categories from decorative labels or alter editorial taxonomy to fit the UI.

Out of scope: loader/schema rewrites, editorial changes, protected images and managed workflows. Changelog permission is separate. This plan authorises no edits.