[jeroendee]

Summary

• Add shared session tags with single-session editing and atomic batch add/remove.
• Add personal AND filters with searchable, bounded choices and independently removable selections. New sessions started from the filtered Sessions list inherit its active tags.
• Find sessions by tag in the launcher; improve narrow-list titles, actions and search wording.

Proof

Original feature evidence: a5774cc (current PR head: 7a264a3). Real isolated app on Linux/Chromium; 19 synthetic sessions seeded with 133 tags and a scripted model. No mocked HTTP responses or production data.

Scenario / expectation	Observed result	Evidence
Single/batch edits persist without replacing unrelated tags or changing recency	Both targets updated; original labels and timestamps preserved	20s desktop demo; API result below
Tag search opens the right session; personal filtering remains separate	Launcher opens the conversation/composer; filter shows exactly 2 matching sessions	Desktop demo and screenshots
Large vocabularies remain usable	Search/no matches, hidden-selection removal and stationary actions work	16s phone demo; 390×844 / 320×500 captures
Invalid batches cannot partially save	Overflow → 409, neither target changes; missing X-Pocket → 403	Actual API checks below

Original validation (a5774cc): npm run check, npm run lint, npm test → 422/422 pass, zero failures/skips. Format, syntax and whitespace checks pass. The committed files match the validated tree.

20-second end-to-end demo:

end-to-end-20s.mp4

API contract and actual response

Authenticated POST /api/sessions/tags: positive-integer ids[]; optional add[] / remove[] names. Names are trimmed/lowercased, 1–32 characters; at most 10 tags per session. Success is {ok:true}; errors are {error:string}.

Actual browser request and response:

POST /api/sessions/tags
Content-Type: application/json
X-Pocket: 1

{"ids":[14,3],"add":["reviewed"],"remove":["shipping"]}
→ 200 {"ok":true}

Subsequent GET /api/sessions confirms both gained reviewed, only session 3 lost shipping, and other labels/updatedAt survived. A batch exceeding 10 tags returned 409 {"error":"A selected session would have more than 10 tags. Nothing was saved."}; before/after metadata matched. Without X-Pocket: 403 {"error":"Missing X-Pocket header"}, no mutation.

Screenshots of changed screens and resulting state

All at a5774cc; phone captures use the identical precommit tree.

16-second phone journey:

filter-phone-16s.mp4

Before → after regressions

List title space: 38979b5 → a32e21f (254px list).

Search wording: a92cd21 → 6beba9d (unchanged sidebar width).

Filter inventory: 6beba9d → a5774cc (390×844, same synthetic vocabulary).

New sessions inherit active tags

At 7a264a3, select tags → Done → Sessions New → folder picker Open creates a session with all selected tags, saved in the initial creation transaction. In the actual native journey, POST /api/sessions with tags: ["polish", "review"] returned HTTP 200 and opened session 29; its stored metadata and matching list row contained both tags. No follow-up tag patch was needed.

Creation regressions pass at desktop, 390×844 and 320×500, including reload persistence, unchanged no-filter behavior, and rejection of 11 tags without partial creation. Backend tests also verify restart persistence. The complete current candidate passed 439/439 tests, zero failures/skips; exact-revision type/lint and regression checks pass.

session-tags-polish-22s.mp4

Local isolated app, real routes/assets and synthetic data; phone sizes use Chromium emulation. Other text/view constraints can still hide a new session.

Limits: local/emulated Chromium, not production, physical-device or screen-reader acceptance. At 320×500, ~3px of the results' lower border initially clips; ~7px outer scrolling reveals it, with all actions reachable. Capture setup needed selector/timing corrections and one aborted-reload retry; the final recorded journey passes.

[TannerMidd]

Thank you, @jeroendee! This is a great feature, and your PR made the case for it clearly. Tags ship in 0.20.0, in a different shape from this PR, so I'm closing it.

Why the change: under our core-or-extension policy, tags are a way to organize work that only some people want (C6). The session list's mechanism goes into core instead, and the tags workflow becomes an extension on top of it (C7). Other extensions can then use the same hooks for status labels, priorities, and similar.

What is on release/0.20.0:

• Core, as experimental extension points:
  • pocket.sessionChips: chips under a row's title.
  • pocket.sessionSearch: words that the sidebar search and the launcher match.
  • pocket.sessionFilter: a filter button in the search field. Its started(id) runs when New starts a session from the filtered list.
  • pocket.sessionAction: an action in a held row's sheet and the selection bar. With an icon, it is also a hover button on rows.
  • request.sessions() on the server: routes check session ids with core's own visibility rule.
• Session tags, a built-in extension that is off by default (src/server/extensions/session-tags.ts). It uses only host, web, and those points. Your limits are kept: lowercase tags of up to 32 characters, 10 per session, and all-or-nothing batch saves. It also has tag chips on rows, AND filtering, tag search in the sidebar and the launcher, a hover tag button, Edit tags for a held row or selected rows, and new sessions that get the active filter's tags. Viewers can read and filter tags, and people invited to one session don't see them.

Tags are stored in the extension's own document, not on SessionMeta. So tagging can't touch updatedAt or the order in Recent, and turning the module off leaves the session list untouched.

You're credited in the commits (668c65b, e191b32, d8b14c4, 0aa7195) and in the policy doc's example section. If you try the release branch and something from your design is missing or feels off, please open an issue. Thanks again!