DonchitosandClaude Opus 5.5
be8993bbc5
Fix release for 1.1.2: the 14 longest skills keep their later phases after a compaction, a question nobody answered is never taken as an answer, settings read the same from a subfolder, the commit check works for a project in a subfolder of a larger repository, every skill opens with a title, and the shipped allow rules no longer approve deleting a branch or writing files without asking. Details in CHANGELOG.md; upgrade steps in UPGRADING.md (v1.1.2 → v1.1.3). Refs #83 Refs #133 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185en4t76fPn7315q4c3nko
3.3 KiB
/architecture-review — Phase 4: Cross-ADR Conflict Detection
Part of
/architecture-review.SKILL.mdnames when to read this file; the settings it resolved and the rules under its later headings still apply here.
Phase 4: Cross-ADR Conflict Detection
Compare every ADR against every other ADR to detect contradictions. A conflict exists when:
- Data ownership conflict: Two ADRs claim exclusive ownership of the same data
- Integration contract conflict: ADR-A assumes System X has interface Y, but ADR-B defines System X with a different interface
- Performance budget conflict: ADR-A allocates N ms to physics, ADR-B allocates N ms to AI, together they exceed the total frame budget
- Dependency cycle: ADR-A says System X initialises before Y; ADR-B says Y initialises before X
- Architecture pattern conflict: ADR-A uses event-driven communication for a subsystem; ADR-B uses direct function calls to the same subsystem
- State management conflict: Two ADRs define authority over the same game state (e.g. both Combat ADR and Character ADR claim to own the health value)
For each conflict found:
## Conflict: [ADR-NNNN] vs [ADR-MMMM]
Type: [Data ownership / Integration / Performance / Dependency / Pattern / State]
ADR-NNNN claims: [...]
ADR-MMMM claims: [...]
Impact: [What breaks if both are implemented as written]
Resolution options:
1. [Option A]
2. [Option B]
ADR Dependency Ordering
After conflict detection, analyse the dependency graph across all ADRs.
Build the graph deterministically — do not trace it by hand:
Bash: bash .claude/scripts/adr-dep-graph.sh
It collects every Depends On edge, runs Kahn's algorithm, and emits
ADRS: / EDGES: / NO_DEPS_SECTION: / CYCLE:. A model tracing A→B→C→A across
a dozen ADRs eventually misses an edge; the algorithm cannot. It reports
observations, not a verdict — you apply the meaning below.
NO_DEPS_SECTION is load-bearing: it makes "no cycles because the graph is
clean" distinguishable from "no cycles because half the ADRs declare no
dependencies". Report the second case as a structural gap, never as a clean graph.
Then interpret:
- Topological sort: the emitted order — ADRs with no dependencies come first (Foundation), ADRs that depend on those come next, etc.
- Flag unresolved dependencies: cross the
EDGES:list against the## Statusvalues already scanned in Phase 1b. If ADR-A depends on an ADR that is stillProposedor does not exist, flag it:⚠️ ADR-0005 depends on ADR-0002 — but ADR-0002 is still Proposed. ADR-0005 cannot be safely implemented until ADR-0002 is Accepted. - Cycle detection: every
CYCLE:line the script emitted is aDEPENDENCY CYCLE— report each one. Do not re-derive them by hand:🔴 DEPENDENCY CYCLE: ADR-0003 → ADR-0006 → ADR-0003 This cycle must be broken before either can be implemented. - Output recommended implementation order:
### Recommended ADR Implementation Order (topologically sorted) Foundation (no dependencies): 1. ADR-0001: [title] 2. ADR-0003: [title] Depends on Foundation: 3. ADR-0002: [title] (requires ADR-0001) 4. ADR-0005: [title] (requires ADR-0003) Feature layer: 5. ADR-0004: [title] (requires ADR-0002, ADR-0005)