Add OpenSpec tech-debt-backlog change

openspec/changes/tech-debt-backlog/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-20

openspec/changes/tech-debt-backlog/proposal.md

@@ -0,0 +1,30 @@
+## Why
+
+We keep turning up small issues during code review and QA triage that
+aren't worth their own OpenSpec change — internal naming nits,
+minor error-severity inconsistencies, leftover dead code, error
+messages that could be clearer, and so on — but they also shouldn't
+disappear into commit-message limbo.
+
+## What Changes
+
+- Create a rolling "backlog" change that collects these small items
+  in one `tasks.md`, grouped by area.
+- Items are added as they come up (from QA triage, self-review,
+  user feedback). Once an item is fixed, its task is marked
+  complete but **not** removed — the archive eventually preserves
+  what was done.
+- When an item grows enough to warrant its own proposal/design
+  (behavior change, new requirement, cross-module impact), it is
+  pulled out into a dedicated OpenSpec change and the backlog entry
+  is marked with a pointer to that change.
+- This change is intentionally long-lived: it stays open until it
+  gets too big to manage, at which point we archive it as a
+  snapshot and start a fresh one.
+
+## Impact
+
+- Affected specs: **none** — this is a process/backlog change, not a
+  requirements change. No `specs/` deltas.
+- Affected code: items land as small PRs referencing their task
+  number in `tech-debt-backlog/tasks.md`.

openspec/changes/tech-debt-backlog/tasks.md

@@ -0,0 +1,25 @@
+## 1. Parser
+
+- [ ] 1.1 Rename `_has_trailing_mutation` in
+  `q_orca/parser/markdown_parser.py` to something that reflects
+  what it actually detects (a mutation op appearing after a gate
+  call within the same effect string). Current name reads like
+  "this effect ends with a mutation" which is misleading.
+  (Source: Hermes QA on PR #21, low severity.)
+
+## 2. Verifier / backend adapters
+
+- [ ] 2.1 Audit CUDA-Q backend error reporting for `severity` /
+  `valid` field consistency. Hermes flagged cases where a result
+  could carry `severity="error"` alongside `valid=True`, or the
+  inverse. Confirm the convention (error severity must mean
+  `valid=False`) and fix any drift.
+  (Source: Hermes QA on PR #21, low severity.)
+
+## 3. How to use this file
+
+- [ ] 3.1 **Meta**: when an item is fixed, leave the task checked
+  rather than deleting it — the archived copy of this change is
+  our record. If an item grows beyond "small," spin it out into
+  a dedicated OpenSpec change and replace the task body with a
+  pointer (e.g. "→ spun out as `add-xyz`").