<feed xmlns='http://www.w3.org/2005/Atom'>
<title>pearl/docs/multi-state-filter-spec.org, branch main</title>
<subtitle>Pearl Edits and Reflects Linear — manage Linear.app issues as org-mode in Emacs
</subtitle>
<id>https://git.cjennings.net/pearl/atom?h=main</id>
<link rel='self' href='https://git.cjennings.net/pearl/atom?h=main'/>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/pearl/'/>
<updated>2026-06-02T04:33:46+00:00</updated>
<entry>
<title>docs: spec for selecting multiple statuses in a filter</title>
<updated>2026-06-02T04:33:46+00:00</updated>
<author>
<name>Craig Jennings</name>
<email>c@cjennings.net</email>
</author>
<published>2026-06-02T04:33:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/pearl/commit/?id=5ef986c880fa6fdfafe3f11943524119065bd044'/>
<id>urn:sha1:5ef986c880fa6fdfafe3f11943524119065bd044</id>
<content type='text'>
I wrote a spec for letting a filter match several workflow states at once. The builder picks one state today, so "Todo or In Review" can't be built. The design makes :state polymorphic, a name or a list of names, mirroring how :state-type already works, so (:state ("Todo" "In Review")) compiles to state.name.in.

It covers the four filter-side readers (compiler, builder, validator, reverse-compile), reconciles the views spec's representability boundary, and notes the issue's own state field is a separate, unaffected use. Codex review incorporated. Status Ready.
</content>
</entry>
</feed>
