goga-review-arch

Architecture Review

Objective

Validate the architecture plan (the file at the path printed by goga history path -f arch.md) for semantic correctness — assess model cohesion, domain boundary soundness, and requirement sufficiency for implementation. The agent analyzes the architecture plan, reports findings, and applies fixes when issues are detected (subject to user approval).

---

Core Principle

Architecture is a cohesive system, not a collection of isolated contracts. The agent validates the interaction across all types, domains, and requirements as a unified whole — not each CODEMANIFEST in isolation.

---

Input

• Required: architecture plan at the path printed by goga history path -f arch.md
• Optional: task file at the path printed by goga history path -f task.md — when present, used to verify requirements coverage

---

Phases

Phase 1: Context Loading

1. Read the architecture plan from the path printed by goga history path -f arch.md
2. Load the DSL specification and DSL application principles:
   • Invoke goga-cell via Skill tool — to understand DSL rules (signature syntax, Import/Usage/Annotation rules, types, mutations, embeddings, constraints)
   • Invoke goga-cookbook via Skill tool — to understand cell and CODEMANIFEST design principles (Entity vs Routine selection criteria, when to apply mutations and embeddings, usage file authoring guidelines, cell granularity)
3. Load language-specific implementation rules:
   • Invoke goga-lang-disp via Skill tool — to obtain the target language skill. The language skill defines implementation conventions: cell structure, facade pattern, signature rules, naming. Examples in other skills may follow naming conventions of one language (e.g., snake_case), whereas the target language requires another (e.g., PascalCase) — the language skill is the authoritative source for the target language.
4. Invoke goga-codemanifest-base via Skill tool — to obtain the project's baseline usages and annotations
5. Retrieve the current project schema:
   • Run goga schema to obtain the existing cell hierarchy
   • Classify plan cells: newly created vs. modified
6. Read the existing CODEMANIFESTs of cells the plan marks for modification
7. Read the existing .usages/ files of cells marked for modification
8. If the task file at the path printed by goga history path -f task.md exists — read it for subsequent requirements coverage verification