Pattern: distinguishing pre-ADR "exploration notes" from formal ADRs in spec-driven-with-adr

[1liuya]

Context

I've been using spec-driven-with-adr for a project where the design
space for a feature was genuinely uncertain — I used /opsx:explore
to work through the problem with the agent before committing to any
change. The exploration surfaced a fairly rich architectural analysis
(multiple viable approaches, trade-offs, and a recommendation for what
to defer vs. build now).

The issue: at that point, no change had been proposed yet, so there
was nowhere in the schema's artifact lifecycle
(proposal → specs + design → adr → tasks) for this reasoning to live.
It either gets lost when the session ends, or gets prematurely forced
into a design/adr artifact before a change actually exists to
attach it to.

The pattern I ended up using

I created a lightweight, informal file outside openspec/ and outside
adr/ (e.g. docs/research-notes/<topic>.md) to capture the raw
exploration — including paths that were considered and rejected, not
just the final recommendation. When the actual change is proposed
later and reaches the design stage, this file is used as input,
not copied verbatim — the formal ADR only records the final decision,
context, and consequences, per the existing ADR format.

The distinction I'd propose naming explicitly:

• Research notes: raw, exploratory, may contain dead ends,
  written before a change exists
• ADR: distilled, decision-oriented, written during a change's
  design stage, per the existing schema

Concrete example

While exploring how a TaskDecomposer agent should handle sub-question
execution (independent vs. dependent vs. parallel), the agent and I
mapped out 7 distinct patterns, with a recommendation to implement
2 of them now and defer the remaining 5 to a later change. That
reasoning was valuable enough to keep, but the change it belongs to
hadn't been proposed yet.

Question for the maintainers/community

Is this already the intended way to use /opsx:explore output, just
not written down anywhere? If so, might be worth a short note in the
schema's README. If not, curious whether this is a pattern others have
run into, and whether it's worth a lighter-weight "research note"
artifact type in the schema itself (optional, not part of the required
lifecycle).

Happy to share more detail on the concrete example if useful.