Instruction file imported from artofdream/adaptive-experience (.cursor/rules/coherence-findings-sop.mdc). Copyright stays with the author.

Coherence findings workflow

When a coherence assessment or the coherence review canvas surfaces inconsistencies or gaps, treat each item as its own unit of work. Do not batch unrelated findings into one MR. Do not leave an open inconsistency or gap without either a queued CF row (intake) or an active remediation cycle.

This SOP is also required by .cursor/rules/claude-obsidian-loop.mdc and research/coherence-findings-loop.md (one queued finding per remediation iteration).

Per finding

1. Intake — Assign or reuse a stable CF-NNN in research/coherence-findings-loop.md when the claim is new or regressed (assessment intake pass; no branch yet).
2. Issue — Open one GitLab issue describing the finding, severity, evidence paths, and the intended fix.
3. Branch — Create one feature branch from updated main, named for the fix (e.g. docs/name-support-faq-publisher).
4. Fix — Change only what that finding requires; keep scope tight. Implement the finding as stated (docs, scripts, CI, or matrix) — do not substitute a drive-by refactor.
5. MR — Open one merge request linked to the issue (Closes #N), with a short summary and test plan. After create or a push that updates that MR, notify @aea-mr-coordinator (.cursor/rules/mr-handoff-to-mrc.mdc).

Path B / UI findings

For live shop / Adaptive Workspace claims, evidence is a journey × viewport clip (phone and desktop), not a screenshot of docs. Follow the Path B section in research/coherence-findings-loop.md. Do not open a parallel UX loop. Do not restyle the shop from a knowledge or intake MR. Do not mark a UI finding verified until the same script is re-recorded after the product merge. Closing the GitLab issue from a spec or CSS MR is not verification. Reconcile the queue from glab. A verified row with no clip dated after CSS is a CF-048-class honesty miss → set regressed. Hourly ticks must not restyle Path B CSS unless @aea-ux-designer.

Ordering

Prefer severity then dependency: medium before low; fix publishers/ownership before dependent traceability rows when both exist.

Intentional / accepted claims

If a review labels something a “gap” but the docs already document it as intentional (with clear criteria), do not open a new fix branch. Record it in the queue as verified or not-reproducible with evidence that the intentional design is documented, and clear it from the open findings list.

Out of scope for this SOP

• Pure risks (e.g. advisory lint) unless the user asks to address them.
• Unrelated refactors, renames, or drive-by doc edits.
• Casual auto-merging of MRs. Loop ticks and sibling skills must not merge. Exception: when @aea-mr-coordinator is invoked and scope, boundary, and validation path all pass, it must set GitLab auto-merge (glab mr merge <n> --yes --auto-merge). Prefer MWPS when the pipeline is still running. Do not wait for a second “please merge this named MR” prompt. Uncertainty → ask @aea-project-manager (process), @aea-product-owner (product accept/reject), or the sponsor (secrets/budget); do not merge and do not set auto-merge. Remediation loop ticks still must not merge unless that skill was invoked.