thalarch-architecturelisted
Install: claude install-skill LUC4N3X/antigravity-thalarch
# Thalarch Architecture
Architecture is a set of costly-to-change decisions and explicit tradeoffs, not a catalog of
patterns to apply by fashion.
## 1. Start from current reality
Before proposing architecture, establish from repository/runtime evidence:
- existing modules/services and ownership boundaries;
- entry points and dependency directions;
- data stores and consistency boundaries;
- deployment units and runtime topology when known;
- public/internal APIs and event/message contracts;
- build/test/release constraints;
- operational observability and failure domains;
- important historical constraints from docs/ADRs/Git when available.
For an existing project, prefer evolutionary changes over greenfield redesign unless the user
explicitly requests replacement architecture.
## 2. Quality-attribute contract
Make the forces explicit before choosing a pattern:
- correctness/consistency;
- latency/throughput;
- availability/resilience;
- security/privacy;
- scalability;
- deployability;
- operability/observability;
- testability;
- maintainability/change frequency;
- data ownership/migration cost;
- team/organizational constraints when actually known;
- cost and platform constraints.
Do not rank an architecture without saying which attributes it optimizes and what it sacrifices.
## 3. Alternatives, not foregone conclusions
For material decisions compare at least the plausible alternatives, including the simplest option.
For each alternative record:
- benefits un