question regarding preference: do you add your specs to an existing namespace of a domain model or do you have a separate spec namespace to share your specs around?

@johnjelinek Here's how we organize the different types of specs we write https://corfield.org/blog/2019/09/13/using-spec/

so, how safe is it to use s/conform as a regex matcher? As in https://juxt.pro/blog/parsing-with-clojure-spec

(s/def ::contentline
  (s/cat
    :name ::iana-token
    :params (s/*
              (s/cat
                :semi #{\;}
                :param-name ::iana-token
                :equals #{\=}
                :param-value ::iana-token))
    :colon #{\:}
    :value ::iana-token))

(s/conform
  ::contentline
  (seq "DTSTART;TZID=US-EAST:20180116T140000"))
=>
{:name [\D \T \S \T \A \R \T],
 :params
 [{:semi \;,
   :param-name [\T \Z \I \D],
   :equals \=,
   :param-value [\U \S \- \E \A \S \T]}],
 :colon \:,
 :value [\2 \0 \1 \8 \0 \1 \1 \6 \T \1 \4 \0 \0 \0 \0]}

(apply str (get-in … [:params 0 :param-value]))
=> "US-EAST"

Thinking about using it to parse recurrence rule from RFC5545 https://icalendar.org/iCalendar-RFC-5545/3-3-10-recurrence-rule.html

we do not recommend using regex specs to parse strings