ase-arch-analyze

@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md @${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md

$ARGUMENTS

<if condition="<ase-project-boxing/> is equal `black`">

The project source artifacts are classified as a *black box*, so
the user does *not* want the architecture inspected or its findings
surfaced. *Skip* the entire investigation and reporting: do *not*
invoke any `Agent` tool and do *not* read any source, only output
the following <template/> and then *SKIP* the remaining steps STEP 2
and STEP 3:

<template>
<ase-tpl-bullet-normal/> **ARCHITECTURE ANALYSIS**: *suppressed* (`project.boxing` is `black`)
</template>

</if>

Investigate the code from an *architectural* perspective. If the
code base is large, you *MUST* use the `Agent` tool (not inline
work) to create multiple sub-agents to split the investigation
task into appropriate chunks.

*Determine* the *target programming language* and the *declared
architecture style* (if any) - e.g., Layered, Hexagonal
(Ports & Adapters), Onion, Clean, CQRS, Microservices,
Event-Driven, Modular Monolith - from code, project documentation,
README files, or folder structure.

Investigate the following architecture quality aspects across
7 thematic blocks:

**Block 1 - Component Boundaries**:

- **SA01 COMPONENT-RESPONSIBILITY**: each component (module,
  class, package) addresses exactly *one single concern* -
  i.e., has exactly *one reason to change*.
- **SA02 COMPONENT-GRANULARITY**: components have *appropriate
  size* - neither monolithic nor fragmented.
- **SA03 COMPONENT-HIERARCHY**: components placed at the *correct
  level* of the component hierarchy (system / program / module /
  class / function).

**Block 2 - Structural Organization**:

- **SA04 LAYERING**: *layers* (horizontal cuts) clearly
  separated, named, and ranked; no upward dependencies.
- **SA05 SLICING**: *slices* (vertical cuts - e.g., feature
  modules, bounded contexts) clearly separated and *cycle-free*.
- **SA06 DEPENDENCY-DIRECTION**: dependencies flow in exactly
  *one direction*; no *circular dependencies*.
- **SA07 REFERENCE-ARCHITECTURE**: *declared-style conformance* -
  the chosen architecture style (see STEP 1 intro for the
  recognized style list) is applied *consistently* throughout
  the codebase, without accidental mixing of styles.

**Block 3 - Architecture Principles**:

- **SA08 COUPLING**: *loose data coupling* between components -
  no *concrete-type dependencies* where abstractions exist, no
  shared data structures leaking across boundaries, communication
  via defined ports / facades / DTOs. (Runtime coupling such as
  races and shared mutable state is covered by SA17.)
- **SA09 COHESION**: *strong cohesion* within each component -
  internal parts (functions, fields, methods) are *tightly
  related*, *co-change*, and share data or behavior; scattered
  helpers that merely coexist by accident are flagged.
- **SA10 EXTENSIBILITY**: components are *open for extension*
  (plugins, SPIs, hooks) but *closed for modification*.
- **SA11 SEPARATION**: *cross-cutting concerns* (logging,
  security, caching, transactions, tracing) isolated from
  domain logic; trace context propagated across component
  boundaries.
- **SA12 ENCAPSULATION**: unavoidable complexity *encapsulated*
  behind a simple interface that *shields* its implementation
  details.