mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 01:37:05 +00:00
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
86 lines
3.3 KiB
Markdown
86 lines
3.3 KiB
Markdown
# /architecture-review — Phase 4: Cross-ADR Conflict Detection
|
|
|
|
> Part of `/architecture-review`. `SKILL.md` names 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:
|
|
|
|
1. **Topological sort**: the emitted order — ADRs with no
|
|
dependencies come first (Foundation), ADRs that depend on those come next, etc.
|
|
2. **Flag unresolved dependencies**: cross the `EDGES:` list against the `## Status`
|
|
values already scanned in Phase 1b. If ADR-A depends on an ADR that is still
|
|
`Proposed` or 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.
|
|
```
|
|
3. **Cycle detection**: every `CYCLE:` line the script emitted is a
|
|
`DEPENDENCY 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.
|
|
```
|
|
4. **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)
|
|
```
|
|
|
|
---
|