devflow-adr-compliance

Skill: devflow-adr-compliance

Knowledge-Hook 6 implementation. Sister-skill to [[devflow-collision-acknowledged]] (Hook 1): together they close the loop — Hook 1 records which ADRs apply to a flow, Hook 6 verifies the implementation actually respects them.

When to use

Trigger this skill at review-time after the implementation is complete and a diff exists. The skill runs against accepted ADRs only; proposed/deprecated/superseded ADRs are not enforced.

Process

0. Snapshot accepted ADRs (before diff-matching)

Before you compare paths, see which ADRs you are being measured against:

adr_list({ status: 'accepted' })

Read each result's affects_paths and title — these are the globs that the backend will run your diff against. Knowing them up front lets you (a) judge override-reasons honestly, (b) catch ADRs whose intent extends beyond their globs, and (c) spot accepted ADRs that obviously cover the area but have empty affects_paths (drift signal — flag as a finding instead of letting the compliance-check silently pass).

1. Collect the changed-files list

Get the file diff between the feature branch and the integration target. Typical command:

git diff --name-only main...HEAD

Pass the resulting array as filesChanged to the backend.

2. Run the compliance check

POST /api/flows/:id/adr-compliance-findings
Body:
{
  "filesChanged": ["backend/src/routes/widgets.js", "frontend/src/pages/X.tsx", ...]
}

Backend matches each path against every accepted ADR's affects_paths globs (minimatch-style: * within a segment, ** across segments, ? single char, escapes elsewhere). Each match becomes a row in flow_compliance_findings with severity='violation'. Re-running the endpoint clears prior findings and records the freshest set.

Response:

{
  "data": {
    "violations": <count>,
    "compliant": <bool>,
    "findings": [
      { id, adrId, adrDisplayId, adrTitle, filePath, severity, overrideReason, overridden, ... }
    ]
  }
}