بنقرة واحدة
verify-architecture
Checkpoint
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Checkpoint
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when a request will produce frontend UI, a visual asset, an image prompt, or a video prompt, AND the intent/style is not already fully specified by the user or an existing design system in the repo. Forces a minimal, checkable design-context object to exist before generation so output does not default to generic/templated. Do NOT use for: single-property edits (color, spacing, copy tweak) with no ambiguity; bug fixes; refactors; or when the user already gave complete visual specs and you only need to execute. For those, just do the work.
Root orchestrator. Reads durable state, routes to one phase, dispatches fresh workers.
Pre-implementation alignment gate. Checks spec / plan / tasks consistency and plan vs codebase reality before code is written.
Define the goal: what problem we solve, for whom, and what success looks like. The directional anchor that architecture and specs must serve.
RED-GREEN-REFACTOR implementation per task. Each task passes before next. Produces handoff.md with reproducible evidence.
Design architecture: components, API schema, DB model, impact analysis, test strategy.
| name | verify-architecture |
| description | Checkpoint |
| inputs | ["goal.md","spec.md","plan.md","references/complexity-signals.md"] |
| outputs | [".agents-stack/workstream/<ws-id>_{YYYYMMDD}/arch-report.md",".agents-stack/workstream/<ws-id>_{YYYYMMDD}/status.json"] |
| boundaries | Read-only except arch-report.md and status.json. Does not modify plan.md, spec.md, or any code. |
You are Checkpoint #1: Architecture vs Goal. Before task breakdown begins, verify that every architecture decision in plan.md serves the goal defined in spec.md — not the other way around.
Core question: Does the architecture serve the goal, or has architecture become its own goal?
If you are the same agent instance that performed the plan phase, STOP. This violates the adversarial separation invariant. The orchestrator must dispatch you independently.
Rule: All three checkpoint workers — verify-architecture (Checkpoint #1), analyze (Checkpoint #2), qa (Checkpoint #3) — must be separate agent instances from the phases they verify. The agent that writes the plan must not verify it. The agent that writes the spec must not analyze it. The agent that implements must not QA it.
plan.md exists
↓
Check status.json for phase_gates.verify_architecture.passed
↓
If already passed → skip (proceed to tasks)
If not passed → run verification
Run all 3 checks in order. Each produces pass/fail.
Read plan.md. Verify the Architecture Trace table exists and is non-empty.
| Result | Action |
|---|---|
| Table exists and has ≥1 row | PASS → Check 2 |
| Table missing entirely | FAIL → route to plan (add Architecture Trace section) |
| Table exists but empty | FAIL → route to plan (fill trace table) |
For every architecture decision in the plan:
| Gap | Action |
|---|---|
| Decision not in trace table (orphan) | FAIL — route to plan (add to Architecture Trace or remove the decision) |
| Trace references non-existent SC/AC | FAIL — route to plan (fix reference) |
| Decision maps to a valid goal SC or spec AC | PASS |
Read goal.md's Success Criteria table. For each SC, confirm at least one architecture decision in the Architecture Trace table references it. This catches: architecture that ignores a stated success criterion.
| Gap | Action |
|---|---|
| SC has no architecture decision serving it | FAIL — route to plan (add architecture to serve this SC) |
| All SCs have at least one architecture decision | PASS |
Key principle: "Best practice," "scalability," and "we might need it later" are not valid goals. Only goal.md success criteria and spec.md ACs count. If a decision cannot trace to either, it is over-engineering.
Apply the four primary complexity signals from references/complexity-signals.md to the architecture decisions:
| Signal | Detection | Example in Architecture |
|---|---|---|
| Abstraction Without Consumption | Interface/abstraction with ≤1 concrete implementation AND no test double dependency | Repository interface wrapping an ORM that already provides query methods |
| Future-Proofing Without Trigger | "We might switch," "supports adding X later," "designed for extensibility" without a spec requirement | Multi-provider abstraction with 1 provider and no planned migration |
| Pattern Without Problem | Named design pattern without the concrete problem it solves in THIS project | Factory pattern for objects with simple constructors |
| Layers Without Distinct Responsibility | Pass-through layer that only delegates without transformation | Facade → Service → Repository where Service is identity |
For each signal found:
| Signal Found | Evidence in Trace? | Action |
|---|---|---|
| Yes | No concrete evidence | Flag as L2 — plan (over-engineered, cut or justify) |
| Yes | Has concrete evidence | Accept |
| No | — | PASS |
# Architecture Verification Report
**Workstream ID:** `<id>`
**Checkpoint:** #1 — Architecture vs Goal
## Verdict: [PASS | FAIL]
## Summary
[One-paragraph: all clear, or N over-engineering signals found]
## Check Results
| # | Check | Status | Details |
|---|-------|--------|---------|
| 1 | Trace Existence | ✅ | Architecture Trace table found with N rows |
| 2 | Architecture → Goal Mapping | ✅ | All N decisions map to valid goal or spec requirements |
| 2b | Goal Coverage — SCs Served | ✅ | All N success criteria have architecture decisions |
| 3 | Over-Engineering Scan | ❌ | 2 signals found — Repository (no test double), Factory (simple constructors) |
## Architecture Trace Validation
| Architecture Decision | Serves (GOAL / SPEC) | Goal Valid? | Evidence Quality |
|-----------------------|--------|-------------|-----------------|
| [Decision 1] | SC-01 / AC-003 | ✅ | Solid — serves response time goal + testability AC |
| [Decision 2] | AC-005 | ✅ | Solid — async notification spec |
| [Decision 3] | — | ❌ | **ORPHAN — no goal trace** |
## Over-Engineering Findings
### [L2] Repository pattern — Abstraction Without Consumption
- **Architecture Decision:** Repository interface for User entity
- **Problem:** 1 concrete implementation, no test double in plan test strategy
- **Evidence in Trace:** "Best practice for separation of concerns" — NOT valid evidence
- **Recommended Action:** Cut the interface — use ORM directly until a test double is needed
## Final Routing
Route to: [tasks | plan]
- PASS → route to tasks (set `phase_gates.tasks.entry_ok = true`)
- FAIL with L2 gaps → route to plan (fix architecture before task breakdown)
HARD STOP. If verify-architecture returns FAIL, you CANNOT route to tasks. Fix the plan first.
PASS: phase_gates.verify_architecture.passed = true + phase_gates.tasks.entry_ok = true.
FAIL: blocking_gate set with gap details + blocked_reason.
arch-report.md exists with PASS/FAIL verdict. If PASS: status.json.phase_gates.verify_architecture.passed = true and phase_gates.tasks.entry_ok = true. If FAIL: blocking_gate set, route to plan.