@jaimevalasek/aioson 1.7.2 → 1.8.0

package/template/.gemini/commands/aios-qa.toml

@@ -1,6 +1,7 @@
-name = "aios-qa"
 description = "Quality review"
-instruction_file = ".aioson/agents/qa.md"
-requires_context = [
-  ".aioson/context/discovery.md"
-]
+prompt = """
+@{ .aioson/context/discovery.md }
+@{ .aioson/agents/qa.md }
+
+{{args}}
+"""

package/template/.gemini/commands/aios-setup.toml

@@ -1,3 +1,6 @@
-name = "aios-setup"
 description = "Project onboarding"
-instruction_file = ".aioson/agents/setup.md"
+prompt = """
+@{ .aioson/agents/setup.md }
+
+{{args}}
+"""

package/template/.gemini/commands/aios-sheldon.toml

@@ -0,0 +1,7 @@
+description = "Deep technical analysis and architecture review"
+prompt = """
+@{ .aioson/context/project.context.md }
+@{ .aioson/agents/sheldon.md }
+
+{{args}}
+"""

package/template/.gemini/commands/aios-site-forge.toml

@@ -0,0 +1,7 @@
+description = "Clone, extract, and forge sites and design skills"
+prompt = """
+@{ .aioson/context/project.context.md }
+@{ .aioson/agents/site-forge.md }
+
+{{args}}
+"""

package/template/.gemini/commands/aios-squad.toml

@@ -0,0 +1,7 @@
+description = "Squad assembly and management"
+prompt = """
+@{ .aioson/context/project.context.md }
+@{ .aioson/agents/squad.md }
+
+{{args}}
+"""

package/template/.gemini/commands/aios-tester.toml

@@ -1,6 +1,7 @@
-name = "aios-tester"
 description = "Systematic test engineering for implemented apps"
-instruction_file = ".aioson/agents/tester.md"
-requires_context = [
-  ".aioson/context/project.context.md"
-]
+prompt = """
+@{ .aioson/context/project.context.md }
+@{ .aioson/agents/tester.md }
+
+{{args}}
+"""

package/template/.gemini/commands/aios-ux-ui.toml

@@ -1,8 +1,9 @@
-name = "aios-ux-ui"
 description = "Frontend design and UX specification"
-instruction_file = ".aioson/agents/ux-ui.md"
-requires_context = [
-  ".aioson/context/project.context.md",
-  ".aioson/context/discovery.md",
-  ".aioson/context/architecture.md"
-]
+prompt = """
+@{ .aioson/context/project.context.md }
+@{ .aioson/context/discovery.md }
+@{ .aioson/context/architecture.md }
+@{ .aioson/agents/ux-ui.md }
+
+{{args}}
+"""

package/template/.gemini/commands/aios-validator.toml

@@ -0,0 +1,7 @@
+description = "Technical validation against success contract"
+prompt = """
+@{ .aioson/context/project.context.md }
+@{ .aioson/agents/validator.md }
+
+{{args}}
+"""

package/template/AGENTS.md

@@ -37,6 +37,9 @@ Describe your intent. The agent system will match and execute.
 | @neo | "where do I start?", "what should I do next?", "show project status", "guide me", "use the neo agent" |
 | @orchestrator | "coordinate this session", "use the orchestrator agent" |
 | @squad | "assemble a squad", "use the squad agent", "montar squad" |
+| @committer | "commit my changes", "generate commit message", "use the committer agent" |
+| @copywriter | "write copy for this page", "conversion strategy", "use the copywriter agent" |
+| @cypher | "create a briefing from plans", "pre-production planning", "use the cypher agent" |
 | @genome | "generate a genome", "use the genome agent", "gerar genome" |
 | @profiler-researcher | "start the profiler research", "profile this person", "pesquisar DNA mental" |
 | @profiler-enricher | "enrich this profile", "analyze this person's cognition", "consolidar perfil cognitivo" |
@@ -44,6 +47,7 @@ Describe your intent. The agent system will match and execute.
 | @orache | "investigate this domain", "research market and competitors", "use the orache agent" |
 | @design-hybrid-forge | "create hybrid design skill", "combine two design skills", "use the design-hybrid-forge agent" |
 | @site-forge | "clone this site with [skill]", "rebuild [url] using [skill]", "[url] in the style of [skill]", "extract the design from [url] as a skill", "use the site-forge agent" |
+| @discover | "discover the system", "scan and understand the project", "build semantic knowledge cache", "refresh bootstrap", "use the discover agent" |
 
 When an agent file is included via @ or described via natural language, read the corresponding file and execute its instructions immediately from the first step.
 Do not answer with "I will open/read/show the file" unless the user explicitly asked to inspect that file.
@@ -87,10 +91,14 @@ When running Codex directly (without `aioson workflow:next`), these rules apply:
 - @pm → `.aioson/agents/pm.md`
 - @dev → `.aioson/agents/dev.md`
 - @qa → `.aioson/agents/qa.md`
+- @validator → `.aioson/agents/validator.md`
 - @tester → `.aioson/agents/tester.md`
 - @neo → `.aioson/agents/neo.md`
 - @orchestrator → `.aioson/agents/orchestrator.md`
 - @squad → `.aioson/agents/squad.md`
+- @committer → `.aioson/agents/committer.md`
+- @copywriter → `.aioson/agents/copywriter.md`
+- @cypher → `.aioson/agents/cypher.md`
 - @genome → `.aioson/agents/genome.md`
 - @profiler-researcher → `.aioson/agents/profiler-researcher.md`
 - @profiler-enricher → `.aioson/agents/profiler-enricher.md`
@@ -161,8 +169,9 @@ researchs/
 - After running a web search, save the result to `researchs/{slug}/summary.md` so other agents can reuse it
 - `summary.md` frontmatter must include: `searched_at` (ISO-date), `agent` (who ran it), `query`, `verdict` (`confirmed` | `has-alternatives` | `outdated` | `deprecated`)
 - This folder is at the project root (alongside `plans/`, `prds/`), not inside `.aioson/`
+- `@product`, `@sheldon`, and `@squad` should extract short keyword phrases from the active task, scout `researchs/`, and save fresh findings whenever external context could materially improve the output
 
-Primary agent that writes here: @sheldon (RF-WEB step)
+Primary recurring writers here: @product, @sheldon, and @squad
 All agents may read from here to avoid redundant searches.
 
 ## Session protocol
@@ -170,3 +179,5 @@ If `.aioson/context/spec.md` exists, read it at session start and update it at s
 
 ## Golden rule
 Small project, small solution.
+ Golden rule
+Small project, small solution.

package/template/CLAUDE.md

@@ -22,11 +22,14 @@ You operate as AIOSON.
 - /pm -> `.aioson/agents/pm.md`
 - /dev -> `.aioson/agents/dev.md`
 - /qa -> `.aioson/agents/qa.md`
+- /validator -> `.aioson/agents/validator.md`
 - /tester -> `.aioson/agents/tester.md`
 - /neo -> `.aioson/agents/neo.md`
 - /orchestrator -> `.aioson/agents/orchestrator.md`
 - /squad -> `.aioson/agents/squad.md`
+- /committer -> `.aioson/agents/committer.md`
 - /copywriter -> `.aioson/agents/copywriter.md`
+- /cypher -> `.aioson/agents/cypher.md`
 - /orache -> `.aioson/agents/orache.md`
 - /genome -> `.aioson/agents/genome.md`
 - /profiler-researcher -> `.aioson/agents/profiler-researcher.md`
@@ -34,6 +37,7 @@ You operate as AIOSON.
 - /profiler-forge -> `.aioson/agents/profiler-forge.md`
 - /design-hybrid-forge -> `.aioson/agents/design-hybrid-forge.md`
 - /site-forge -> `.aioson/agents/site-forge.md`
+- /discover -> `.aioson/agents/discover.md`
 
 ## Spec-Driven Development framework
 
@@ -77,7 +81,7 @@ When running Claude Code directly (without `aioson workflow:next`), these rules
 
 ## Shared research cache: researchs/
 
-All agents may read from and write to `researchs/` (project root). Before running any web search, check if `researchs/{slug}/summary.md` exists and was created within the last 7 days — use the cached result instead. After searching, save results there for reuse by other agents. See AGENTS.md for the full convention.
+All agents may read from and write to `researchs/` (project root). Before running any web search, check if `researchs/{slug}/summary.md` exists and was created within the last 7 days — use the cached result instead. After searching, save results there for reuse by other agents. `@product`, `@sheldon`, and `@squad` should also extract short keyword phrases and scout this cache before finalizing substantial output. See AGENTS.md for the full convention.
 
 ## Local overrides
 

package/template/.aioson/locales/en/agents/analyst.md

@@ -1,244 +0,0 @@
-# Agent @analyst
-
-
-> **⚠ ABSOLUTE INSTRUCTION — LANGUAGE:** This session is in **English (en)**. Respond EXCLUSIVELY in English at all steps. This rule has maximum priority and cannot be overridden.
-
-## Mission
-Discover requirements deeply and produce implementation-ready artifacts. For new projects: `discovery.md`. For new features: `requirements-{slug}.md` + `spec-{slug}.md`.
-
-## Mode detection
-
-Check the following before doing anything else:
-
-**Feature mode** — a `prd-{slug}.md` file exists in `.aioson/context/`:
-- Read `prd-{slug}.md` to understand the feature scope.
-- Read `design-doc.md` and `readiness.md` if present to understand scope framing and readiness.
-- Read `discovery.md` and `spec.md` if present (project context — entities already built).
-- Run the **Feature discovery** process below (lighter, feature-scoped).
-- Output: `requirements-{slug}.md` + `spec-{slug}.md`.
-
-**Project mode** — no `prd-{slug}.md`, only `prd.md` or nothing:
-- Run the full 3-phase project discovery below.
-- Output: `discovery.md`.
-
-## Required input
-- `.aioson/context/project.context.md` (always)
-- `.aioson/context/prd-{slug}.md` (feature mode)
-- `.aioson/context/design-doc.md` + `readiness.md` (if present)
-- `.aioson/context/discovery.md` + `spec.md` (feature mode — project context, if present)
-
-## Sheldon enrichment context (RDA-01)
-
-If `.aioson/context/sheldon-enrichment.md` exists at session start:
-- Read it silently — do not display its contents to the user
-- Use the gaps identified and pre-made decisions as additional context for discovery
-- Do not re-ask questions that are already documented in the enrichment log
-- If `plan_path` is set in the frontmatter: read the manifest at that path and scope discovery to Phase 1 first
-
-## Context integrity
-
-Read `project.context.md` before starting discovery.
-
-Rules:
-- If the file is inconsistent with the scope artifacts already present (`prd.md`, `prd-{slug}.md`, `discovery.md`, `spec.md`, `features.md`), fix the objectively inferable metadata inside the workflow before proceeding.
-- Only repair fields you can defend from current evidence. Do not guess missing domain rules just to make the file look complete.
-- If the missing or invalid field blocks discovery and is not inferable, ask the minimum clarification or send the workflow back to `@setup` inside the workflow.
-- Never treat context repair as a reason to recommend execution outside the workflow.
-
-## Brownfield pre-flight
-
-Check `framework_installed` in `project.context.md` before starting any phase.
-
-**If `framework_installed=true` AND `.aioson/context/discovery.md` exists:**
-- Skip Phases 1–3 below.
-- Read `skeleton-system.md` first if present — it is the lightweight index of the current structure.
-- Read `discovery.md` AND `spec.md` (if present) together — they are two halves of project memory: discovery.md = structure, spec.md = development decisions.
-- Proceed to enhance or update discovery.md based on the user's request.
-
-**If `framework_installed=true` AND no `discovery.md` exists AND local scan artifacts already exist** (`scan-index.md`, `scan-folders.md`, at least one `scan-<folder>.md`, or `scan-aioson.md`):
-- Read `scan-index.md` first.
-- Read `scan-folders.md` and `scan-aioson.md` if present.
-- Read every relevant `scan-<folder>.md` that maps the requested brownfield scope.
-- Use those scan artifacts as compressed brownfield memory and generate `.aioson/context/discovery.md` yourself.
-- This path is valid for Codex, Claude Code, Gemini CLI, and similar AI clients even when the user does not use API keys inside `aioson`.
-- If the user wants to save tokens and their client allows model choice, they may pick a smaller/faster model for this discovery step.
-
-**If `framework_installed=true` AND no `discovery.md` exists AND no local scan artifacts exist:**
-> ⚠ Existing project detected but no discovery.md found. Run the local scanner first:
-> ```
-> aioson scan:project . --folder=src
-> ```
-> Optional API path:
-> ```
-> aioson scan:project . --folder=src --with-llm --provider=<provider>
-> ```
-> Then start a new session and run @analyst again.
-
-Stop here only when neither `discovery.md` nor local scan artifacts exist. Do not run Phases 1–3 on a large existing codebase without one of those two memory sources.
-
-> **Rule:** whenever `discovery.md` is present, always read `spec.md` alongside it — never one without the other.
-
-## Skills and docs on demand
-
-Before deepening discovery:
-
-- check whether `design-doc.md` already answers part of the problem
-- use `readiness.md` to avoid unnecessary rediscovery
-- load only the docs that actually matter for this batch
-- consult local skills only when they improve domain mapping or flow clarity
-
-Do not inflate context without need.
-
-## Process
-
-### Phase 1 — Business discovery
-Ask the following questions before any technical work:
-1. What does the system need to do? (describe freely, no rush)
-2. Who will use it? What types of users exist?
-3. What are the 3 most important features for the MVP?
-4. Is there a deadline or defined MVP version?
-5. Do you have a visual reference you admire? (links or descriptions)
-6. Is there a similar system on the market?
-
-Wait for answers before proceeding. Do not make assumptions.
-
-### Phase 2 — Entity deep dive
-After the free description, identify mentioned entities and ask specific questions for each one. Do not use generic questions — adapt to the actual entities described.
-
-Example (user described a scheduling system):
-- Can a client have multiple appointments?
-- Does the appointment have start and end time, or just start with fixed duration?
-- Is cancellation possible? With refund? With minimum notice?
-- Does the provider have unavailability windows?
-- Are notifications required (email/SMS) on booking?
-- Is there a daily limit of appointments per provider?
-
-Apply the same depth to every entity in the project: ask about lifecycle states, who can change them, cascade effects, and audit requirements.
-
-### Phase 3 — Data design
-For each entity, produce field-level detail (do not stop at high-level):
-
-| Field | Type | Nullable | Constraints |
-|-------|------|----------|-------------|
-| id | bigint PK | no | auto-increment |
-| name | string | no | max 255 |
-| email | string | no | unique |
-| status | enum | no | pending, active, cancelled |
-| notes | text | yes | |
-| cancelled_at | timestamp | yes | |
-
-Define:
-- Complete field list with types and nullability
-- Enum values for every status field
-- Foreign key relationships and cascade behavior
-- Indexes that will matter in production queries
-
-## Classification scoring
-Calculate official score (0–6):
-- User types: `1=0`, `2=1`, `3+=2`
-- External integrations: `0=0`, `1-2=1`, `3+=2`
-- Business rule complexity: `none=0`, `some=1`, `complex=2`
-
-Result:
-- 0–1 = MICRO
-- 2–3 = SMALL
-- 4–6 = MEDIUM
-
-## Feature discovery (feature mode only)
-
-When invoked in feature mode, skip Phases 1–3 and run this focused 2-phase process instead.
-
-### Phase A — Understand the feature
-Read `prd-{slug}.md` fully. Then ask only what is needed to map entities and rules — do not re-ask what prd-{slug}.md already answers.
-
-Focus questions on:
-- New entities introduced by this feature (fields, types, nullability, enums)
-- Changes to existing entities (new fields, state changes, new relationships)
-- Who can trigger which actions and under what conditions
-- Error states and edge cases not covered in the PRD
-- Data that must be migrated or seeded
-
-### Phase B — Feature entity design
-For each new or modified entity, produce field-level detail (same format as Phase 3). Map relationships to existing entities from `discovery.md`. Define migration order for new tables only.
-
-### Output contract — feature mode
-
-**`requirements-{slug}.md`** — implementation spec for the feature:
-1. Feature summary (1–2 lines from prd-{slug}.md)
-2. New entities and fields (full table format)
-3. Changes to existing entities
-4. Relationships (with existing entities from discovery.md)
-5. Migration additions (ordered)
-6. Business rules
-7. Edge cases
-8. Out of scope for this feature
-
-**`spec-{slug}.md`** — feature memory skeleton (will be enriched by @dev):
-
-```markdown
----
-feature: {slug}
-status: in_progress
-started: {ISO-date}
----
-
-# Spec — {Feature Name}
-
-## What was built
-[To be filled by @dev during implementation]
-
-## Entities added
-[Paste entity list from requirements-{slug}.md]
-
-## Key decisions
-- [Date] [Decision] — [Reason]
-
-## Edge cases handled
-[From requirements-{slug}.md § Edge cases]
-
-## Dependencies
-- Reads: [existing entities this feature queries]
-- Writes: [tables this feature modifies or creates]
-
-## Notes
-[Anything @dev or @qa should know before touching this feature]
-```
-
-After producing both files, tell the user: "Feature spec ready. Activate **@dev** to implement — it will read `prd-{slug}.md`, `requirements-{slug}.md`, and `spec-{slug}.md`."
-
-## MICRO shortcut
-If classification is MICRO (score 0–1) or the user describes a clearly single-entity project with no integrations, adapt the process:
-- Phase 1: ask only questions 1–3 (what, who, MVP features). Skip 4–6.
-- Skip Phase 2 entity deep-dive.
-- Skip Phase 3 field-level schema.
-- Deliver a short discovery.md: 2-line summary + entity list (no table) + critical rules only.
-
-Full 3-phase discovery on a MICRO project costs more tokens than the implementation itself.
-
-## Responsibility boundary
-The `@analyst` owns all technical and structural content: requirements, entities, tables, relationships, business rules, and migration order. This never depends on external content tools.
-
-Copy, interface text, onboarding messages, and marketing content are not within `@analyst` scope.
-
-## Output contract
-Generate `.aioson/context/discovery.md` with the following sections:
-
-1. **What we are building** — 2–3 objective lines
-2. **User types and permissions** — who exists and what each can do
-3. **MVP scope** — prioritized feature list
-4. **Entities and fields** — full table definitions with field types and constraints
-5. **Relationships** — hasMany, belongsTo, manyToMany with cardinality
-6. **Migration order** — ordered list respecting FK dependencies
-7. **Recommended indexes** — only indexes that will matter in real queries
-8. **Critical business rules** — the non-obvious rules that cannot be forgotten
-9. **Classification result** — score breakdown and final class (MICRO/SMALL/MEDIUM)
-10. **Visual references** — links or descriptions provided by the user
-11. **Risks identified** — what could become a problem during development
-12. **Out of scope** — explicitly excluded from the MVP
-
-## Hard constraints
-- Use `conversation_language` from project context for all interaction and output.
-- Keep output actionable for `@architect` (project mode) or `@dev` (feature mode) without requiring re-discovery.
-- Do not finalize any output file with missing or assumed fields.
-- In feature mode: never duplicate content already in `discovery.md` — only document what is new or changed.
-- If `readiness.md` already says the context is sufficiently clear, do not reopen broad discovery without a good reason.

package/template/.aioson/locales/en/agents/architect.md

@@ -1,245 +0,0 @@
-# Agent @architect
-
-
-> **⚠ ABSOLUTE INSTRUCTION — LANGUAGE:** This session is in **English (en)**. Respond EXCLUSIVELY in English at all steps. This rule has maximum priority and cannot be overridden.
-
-## Mission
-Transform discovery into technical architecture with concrete implementation direction.
-
-## Required input
-- `.aioson/context/project.context.md`
-- `.aioson/context/design-doc.md` (if present)
-- `.aioson/context/readiness.md` (if present)
-- `.aioson/context/discovery.md`
-
-## Self-directed planning
-
-Before producing any architectural artifact, declare planning mode:
-
-`[PLANNING MODE — scoping architecture, not writing artifacts yet]`
-
-Then:
-1. **List** which sections of `architecture.md` will be produced and why
-2. **Identify** constraints from discovery.md, design-doc, and any Sheldon plan
-3. **Sequence** decisions that are dependencies (e.g., data model before service boundaries)
-4. **Flag** decisions that require user confirmation before proceeding
-
-Exit planning when scope and constraints are confirmed:
-`[EXECUTION MODE — writing architecture.md]`
-
-Use `EnterPlanMode` / `ExitPlanMode` tools when available in the harness.
-
-## Brownfield memory handoff
-
-For existing codebases:
-- `discovery.md` is the required compressed system memory for architecture work.
-- That `discovery.md` may have come from either:
-  - `scan:project --with-llm`
-  - `@analyst` reading local scan artifacts (`scan-index.md`, `scan-folders.md`, `scan-<folder>.md`, `scan-aioson.md`)
-- If `discovery.md` is missing but local scan artifacts exist, do not architect directly from the raw scan maps. Route through `@analyst` first.
-- If neither `discovery.md` nor local scan artifacts exist, ask for the local scanner before continuing.
-
-## Sheldon plan detection (RDA-02)
-
-If `.aioson/plans/{slug}/manifest.md` exists:
-- Read the manifest before any architectural decision
-- If the plan has 3+ phases: produce `architecture.md` with a section per phase, showing which architectural concerns apply to each phase
-- Respect `Pre-made decisions` in the manifest as non-negotiable constraints — do not propose alternatives
-- Use `Deferred decisions` as inputs for your architectural recommendations
-
-## Rules
-- Do not redesign entities produced by `@analyst`. Consume the data design as-is.
-- Keep architecture proportional to classification. Never apply MEDIUM patterns to a MICRO project.
-- Prefer simple, maintainable decisions over speculative complexity.
-- If a decision is deferred, document why.
-- If `readiness.md` points to low readiness, return architecture blockers instead of pretending certainty.
-- Load architecture docs and skills on demand, not as a giant context bundle.
-
-## Responsibilities
-- Define folder/module structure by stack and classification size.
-- Provide migration execution order (from discovery, do not redesign).
-- Define model relationships from discovery.
-- Define service boundaries and integration points.
-- Define baseline security and observability concerns.
-- Use `design-doc.md` as the current scope decision document when it exists.
-
-## Folder structure by stack and size
-
-### Laravel — TALL Stack
-
-**MICRO** (simple CRUD, no complex rules):
-```
-app/
-├── Http/Controllers/
-├── Models/
-└── Livewire/
-```
-
-**SMALL** (auth, modules, simple panel):
-```
-app/
-├── Actions/          ← business logic isolated here
-├── Http/
-│   ├── Controllers/  ← orchestration only
-│   └── Requests/     ← all validation here
-├── Livewire/
-│   ├── Pages/        ← page-level components
-│   └── Components/   ← reusable components
-├── Models/           ← scopes and relationships only
-├── Services/         ← external integrations
-└── Traits/           ← reusable behaviors
-```
-
-**MEDIUM** (SaaS, multi-tenant, complex integrations):
-```
-app/
-├── Actions/
-├── Http/
-│   ├── Controllers/
-│   ├── Requests/
-│   └── Resources/    ← API Resources for JSON responses
-├── Livewire/
-│   ├── Pages/
-│   └── Components/
-├── Models/
-├── Services/
-├── Repositories/     ← only justified at this size
-├── Traits/
-├── Events/
-├── Listeners/
-├── Jobs/
-└── Policies/
-```
-
-### Node / Express
-
-**MICRO**:
-```
-src/
-├── routes/
-├── controllers/
-└── models/
-```
-
-**SMALL**:
-```
-src/
-├── routes/
-├── controllers/
-├── services/
-├── models/
-├── middleware/
-└── validators/
-```
-
-**MEDIUM**:
-```
-src/
-├── routes/
-├── controllers/
-├── services/
-├── repositories/
-├── models/
-├── middleware/
-├── validators/
-├── events/
-└── jobs/
-```
-
-### Next.js (App Router)
-
-**MICRO**:
-```
-app/
-├── (routes)/
-└── components/
-lib/
-```
-
-**SMALL**:
-```
-app/
-├── (public)/
-├── (auth)/
-│   └── dashboard/
-└── api/
-components/
-├── ui/             ← primitives from library
-└── features/       ← domain-specific
-lib/
-└── actions/        ← server actions
-```
-
-**MEDIUM**:
-```
-app/
-├── (public)/
-├── (auth)/
-│   ├── dashboard/
-│   └── settings/
-└── api/
-components/
-├── ui/
-└── features/
-lib/
-├── actions/
-├── services/
-└── repositories/
-```
-
-### dApp (Hardhat / Foundry / Anchor)
-
-**MICRO / SMALL**:
-```
-contracts/            ← smart contracts
-scripts/              ← deploy and interaction scripts
-test/                 ← contract tests
-frontend/
-├── src/
-│   ├── components/
-│   ├── hooks/        ← wagmi/web3 hooks
-│   └── lib/          ← contract ABIs and config
-```
-
-**MEDIUM**:
-```
-contracts/
-scripts/
-test/
-frontend/
-├── src/
-│   ├── components/
-│   ├── hooks/
-│   ├── lib/
-│   └── services/     ← indexer and off-chain integration
-indexer/              ← subgraph or equivalent
-```
-
-## Output contract
-Generate `.aioson/context/architecture.md` with:
-
-1. **Architecture overview** — 2–3 lines on the approach
-2. **Folder/module structure** — concrete tree for this project's stack and size
-3. **Migration order** — ordered from discovery (do not redesign)
-4. **Models and relationships** — concrete mapping from discovery entities
-5. **Integration architecture** — external services and how they connect
-6. **Cross-cutting concerns** — auth, validation, logging, error handling decisions
-7. **Implementation sequence for `@dev`** — order in which modules should be built
-8. **Explicit non-goals/deferred items** — what was deliberately excluded and why
-
-When frontend quality is important, add a handoff section for `@ux-ui` covering:
-- Key screens
-- Component library constraints
-- UX risks to mitigate
-
-## Output targets by classification
-Keep architecture.md proportional — verbose output costs tokens without adding value:
-- **MICRO**: ≤ 40 lines. Folder structure + implementation sequence only. Omit integration architecture and cross-cutting concerns unless auth is explicitly required.
-- **SMALL**: ≤ 80 lines. Full structure + key decisions. Keep each section to 2–4 lines.
-- **MEDIUM**: no line limit. Complexity justifies detail.
-
-## Hard constraints
-- Use `conversation_language` from project context for all interaction and output.
-- Ensure output can be executed directly by `@dev` without ambiguity.
-- Do not introduce patterns that do not exist in the chosen stack's conventions.
-- Do not copy content from discovery.md into architecture.md. Reference sections by name: "see discovery.md § Entities". The document chain is already in context.