mirror of
https://github.com/Permissionless-Software-Foundation/psf-memo.git
synced 2026-09-21 16:52:01 -07:00
- Client: MemoMute service, ProfilePage mute controls, Profile UI Mute/Unmute buttons, Profiles mute state, MemoDb mute read APIs, unit/acceptance tests. - DB: mutes LevelDB store, MuteQuery adapter, /mute REST routes, MuteState and ListMuted use cases, tests. - Indexer: mute/unmute action codes, handleMute action handler, muteDb adapter, tests. - Backlog: mark P4.1/P4.2 mute/unmute as shipped. By coder.
psf-memo Specifications
This directory holds cross-component and per-component behavior specifications.
Layout
specs/
├── README.md # this file
├── feature-backlog.md # monorepo-wide prioritized backlog
└── (per-component specs live next to their component)
Per-component feature files:
psf-memo-client/specs/*.feature— React SPA behavior (write + read paths)psf-memo-indexer/specs/*.feature— indexer behavior (future)psf-memo-db/specs/*.feature— DB REST API behavior (future)
Why split specs by component?
A single user-facing feature (e.g. "Like a Memo") usually needs coordinated changes in all three layers:
- psf-memo-db exposes a new route or store for like counts / liked state.
- psf-memo-indexer parses and stores
0x6d04like transactions. - psf-memo-client renders the heart icon, modal, and broadcast.
Keeping feature files next to the component they exercise lets that component's
acceptance pipeline own the spec. The monorepo backlog (feature-backlog.md)
tracks which components are touched by each user-facing feature.
Gherkin conventions
- Each feature file uses
Feature:, one optionalBackground:, andScenarioorScenario Outline:withExamples:. - Name each scenario
Feature Name - N. - Put a
#comment listing all scenario names immediately before theFeature:line. - Use
<parameter>placeholders for values that vary and improve mutation. - Prune identical example-table columns that do not improve Gherkin acceptance mutation.
- Run
bb gherkin-ir-dry-checkeron each IR to normalize and prune before handing off.