d69da6d627
Major changes: - Add internal/logging package with field constants, context propagation, sensitive data auto-redaction, and per-component log levels - Add worker timeout constants (TimeoutQuickOp, TimeoutHealthCheck, etc.) - Extend SDLC with callback handlers, generate endpoints, and executor - Add new cookbook trees for aeries and slackpath progression - Add skeleton templates for queue, realtime, and microservices - Add worker component template with async job processing - Refactor services and handlers to use new logging infrastructure - Split component.go into component_infra.go and component_listing.go Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
64 lines
2.6 KiB
Markdown
64 lines
2.6 KiB
Markdown
# Aeries Preparation Analysis
|
|
|
|
The Aeries project follows an "Evolutionary Architecture" path: Monolith -> Split -> Distributed. This requires specific preparation to ensure the Monolith is built in a way that *can* be split later without a full rewrite.
|
|
|
|
## 1. The Critical Pattern: "Interface-First"
|
|
|
|
For `aeries-1-genesis` to succeed as a precursor to `aeries-2-simulation`, the Core API must NOT tightly couple its HTTP handlers to its Logic.
|
|
|
|
**BAD Pattern (Hard to split):**
|
|
```go
|
|
// Handler directly calls DB logic
|
|
func CreateAgent(w, r) {
|
|
db.Exec("INSERT INTO agents...")
|
|
}
|
|
```
|
|
|
|
**GOOD Pattern (Easy to split):**
|
|
```go
|
|
// Handler calls Interface
|
|
type AgentService interface {
|
|
Create(ctx, agent) error
|
|
}
|
|
|
|
func CreateAgent(svc AgentService) http.HandlerFunc {
|
|
return func(w, r) {
|
|
svc.Create(...)
|
|
}
|
|
}
|
|
```
|
|
|
|
**Requirement:** We need to update the `go-api` template (or the `implement-feature` prompt instructions) to enforce this Hexagonal/Clean Architecture style.
|
|
|
|
## 2. Infrastructure Gaps
|
|
|
|
Aeries uses standard components, but expects them to be "peelable".
|
|
|
|
* **Postgres:** Required immediately (same as Slack path).
|
|
* **React App:** Required immediately. We have `astro-landing`, but do we have a robust `app-react` template? The cookbook assumes `type: app-react`.
|
|
* *Action:* Check `internal/adapter/templates/templates/app-react`. If missing, create it (likely based on Vite + Tailwind).
|
|
|
|
## 3. SDLC Commands for Evolution
|
|
|
|
The later stages of Aeries depend on the Agent's ability to Refactor.
|
|
|
|
* **`refactor-extract` Command:** We need a command that specifically handles the "Phase 2" logic:
|
|
1. Copy package `X` to new Service `Y`.
|
|
2. Delete package `X` from Core.
|
|
3. Generate `X_Client` in Core that talks to Service `Y`.
|
|
|
|
## 4. Preparation Checklist
|
|
|
|
### Immediate (For Genesis)
|
|
1. [ ] **Templates:** Verify/Create `postgres` and `app-react`.
|
|
2. [ ] **Instructions:** Update `.claude/skills/code-review` or create `.claude/skills/go-architecture` to enforce Interface-based design so the agent doesn't write spaghetti code.
|
|
|
|
### Future (For Simulation/Society)
|
|
3. [ ] **Command:** Create `.claude/commands/extract-service.md`.
|
|
4. [ ] **Template:** Ensure `worker` template exists (for the Simulation tick).
|
|
5. [ ] **Template:** Ensure `redis` template exists (for the Society pub/sub).
|
|
|
|
## Risk Assessment
|
|
|
|
The biggest risk to Aeries is that the Agent writes a "Script Kiddie" monolith (everything in `main.go` or tight coupling) which becomes impossible to refactor autonomously. We must prompt-engineer the "Good Architecture" into the system *before* the first line of Aeries code is written.
|