@jaimevalasek/aioson 1.7.0 → 1.8.0

package/template/.aioson/agents/manifests/pm.manifest.json

@@ -0,0 +1,26 @@
+{
+  "agent_id": "pm",
+  "version": "1.0",
+  "display_name": "PM",
+  "capabilities": [
+    {
+      "id": "plan_delivery",
+      "category": "orchestrate",
+      "description": "Refine PRD delivery sequencing and acceptance criteria for the approved scope.",
+      "inputs": [
+        { "type": "artifact", "path_pattern": ".aioson/context/prd.md", "required": false },
+        { "type": "artifact", "path_pattern": ".aioson/context/prd-{slug}.md", "required": false },
+        { "type": "artifact", "path_pattern": ".aioson/context/architecture.md", "required": false },
+        { "type": "artifact", "path_pattern": ".aioson/context/ui-spec.md", "required": false }
+      ],
+      "outputs": [
+        { "type": "artifact", "path_pattern": ".aioson/context/prd.md" },
+        { "type": "artifact", "path_pattern": ".aioson/context/prd-{slug}.md" }
+      ]
+    }
+  ],
+  "autonomy_modes": ["guarded"],
+  "default_mode": "guarded",
+  "supported_tools": ["codex", "claude", "gemini", "opencode"],
+  "risk_profile": "low"
+}

package/template/.aioson/agents/manifests/product.manifest.json

@@ -0,0 +1,23 @@
+{
+  "agent_id": "product",
+  "version": "1.0",
+  "display_name": "Product",
+  "capabilities": [
+    {
+      "id": "define_product_scope",
+      "category": "create",
+      "description": "Produce the PRD for a project or feature scope.",
+      "inputs": [
+        { "type": "artifact", "path_pattern": ".aioson/context/project.context.md", "required": true }
+      ],
+      "outputs": [
+        { "type": "artifact", "path_pattern": ".aioson/context/prd.md" },
+        { "type": "artifact", "path_pattern": ".aioson/context/prd-{slug}.md" }
+      ]
+    }
+  ],
+  "autonomy_modes": ["guarded"],
+  "default_mode": "guarded",
+  "supported_tools": ["codex", "claude", "gemini", "opencode"],
+  "risk_profile": "medium"
+}

package/template/.aioson/agents/manifests/qa.manifest.json

@@ -0,0 +1,25 @@
+{
+  "agent_id": "qa",
+  "version": "1.0",
+  "display_name": "QA",
+  "capabilities": [
+    {
+      "id": "verify_feature",
+      "category": "verify",
+      "description": "Evaluate implementation against acceptance criteria and risk.",
+      "inputs": [
+        { "type": "artifact", "path_pattern": ".aioson/context/prd-{slug}.md", "required": false },
+        { "type": "artifact", "path_pattern": "src/**/*", "required": false },
+        { "type": "gate", "path_pattern": "gate:D", "required": false }
+      ],
+      "outputs": [
+        { "type": "artifact", "path_pattern": ".aioson/context/qa-report-{slug}.md" },
+        { "type": "gate", "path_pattern": "gate:D" }
+      ]
+    }
+  ],
+  "autonomy_modes": ["guarded"],
+  "default_mode": "guarded",
+  "supported_tools": ["codex", "claude", "gemini", "opencode"],
+  "risk_profile": "low"
+}

package/template/.aioson/agents/manifests/setup.manifest.json

@@ -0,0 +1,20 @@
+{
+  "agent_id": "setup",
+  "version": "1.0",
+  "display_name": "Setup",
+  "capabilities": [
+    {
+      "id": "initialize_project_context",
+      "category": "create",
+      "description": "Create or repair the baseline project context for AIOSON.",
+      "inputs": [],
+      "outputs": [
+        { "type": "artifact", "path_pattern": ".aioson/context/project.context.md" }
+      ]
+    }
+  ],
+  "autonomy_modes": ["guarded"],
+  "default_mode": "guarded",
+  "supported_tools": ["codex", "claude", "gemini", "opencode"],
+  "risk_profile": "medium"
+}

package/template/.aioson/agents/manifests/ux-ui.manifest.json

@@ -0,0 +1,24 @@
+{
+  "agent_id": "ux-ui",
+  "version": "1.0",
+  "display_name": "UI/UX",
+  "capabilities": [
+    {
+      "id": "design_ui_spec",
+      "category": "create",
+      "description": "Produce UI specification and visual direction for the approved scope.",
+      "inputs": [
+        { "type": "artifact", "path_pattern": ".aioson/context/architecture.md", "required": true },
+        { "type": "artifact", "path_pattern": ".aioson/context/prd.md", "required": false },
+        { "type": "artifact", "path_pattern": ".aioson/context/prd-{slug}.md", "required": false }
+      ],
+      "outputs": [
+        { "type": "artifact", "path_pattern": ".aioson/context/ui-spec.md" }
+      ]
+    }
+  ],
+  "autonomy_modes": ["guarded"],
+  "default_mode": "guarded",
+  "supported_tools": ["codex", "claude", "gemini", "opencode"],
+  "risk_profile": "medium"
+}

package/template/.aioson/agents/neo.md

@@ -5,12 +5,8 @@
 ## Mission
 Be the single entry point for AIOSON sessions. See the full picture — project state, workflow stage, pending work — and guide the user to the right agent. Never implement, never produce artifacts. Your only job: orient and route.
 
-## Language detection
-Before any other action, detect the language of the user's first message:
-- Portuguese → check `.aioson/locales/pt-BR/agents/neo.md` → if yes, use it
-- Spanish → check `.aioson/locales/es/agents/neo.md` → same
-- French → check `.aioson/locales/fr/agents/neo.md` → same
-- English or locale not found → continue here
+## Language boundary
+Use the project's `interaction_language` for all user-facing communication. If `interaction_language` is absent, fall back to `conversation_language`. If neither is available, match the user's message language.
 
 ## Identity
 You are **Neo**. You see the matrix — the full state of the project, the workflow, and where the user is. You don't do the work. You show the path.
@@ -21,6 +17,8 @@ Tone: calm, direct, confident. No filler. You present what you found, ask one fo
 
 On activation, run the diagnostic sequence below and present results. Do not wait for user input before running diagnostics.
 
+If `aioson` is available, run `aioson memory:summary . --last=5` before the table scan. Use it as the fast session bootstrap for recent work, runtime history, bootstrap coverage, and retrieval hints. Do not require the user to know or run this command.
+
 ## Project pulse (read at session start)
 
 If `.aioson/context/project-pulse.md` exists, read it before any routing decision. It provides:
@@ -71,6 +69,7 @@ Check these in order. Stop at the first failure:
 | Dev state | `.aioson/context/dev-state.md` | If present: @dev has an active session. Read `active_feature`, `active_phase`, `next_step`, `status` — this is the strongest signal for "implementation in progress" |
 | Features active | `.aioson/context/features.md` | Note in-progress features |
 | Design doc | `.aioson/context/design-doc*.md` | Note presence |
+| Copy exists | `.aioson/context/copy-*.md` | Only relevant when `project_type=site`. If missing: flag `needs_copy` — @copywriter must run before @ux-ui or @dev |
 | Readiness | `.aioson/context/readiness.md` | If exists, read status |
 | Implementation plan | `.aioson/context/implementation-plan.md` | Note presence and status |
 | Skeleton system | `.aioson/context/skeleton-system.md` | Note presence |
@@ -94,7 +93,8 @@ Based on Step 1 results, classify the project into one of these stages:
 | **Needs product definition** | Context valid, no PRD | `/product` |
 | **Needs analysis** | PRD exists, no discovery | `/analyst` |
 | **Needs architecture** | Discovery exists, no architecture | `/architect` |
-| **Ready to implement** | Architecture exists, no active implementation | `/dev` |
+| **Needs copy** | `project_type=site`, no `copy-{slug}.md` in `.aioson/context/` | `/copywriter` |
+| **Ready to implement** | Architecture exists (or `site` with copy ready), no active implementation | `/dev` |
 | **Implementation in progress** | `dev-state.md` exists with `status: in_progress` — strongest signal; or spec exists with open items, or feature branch active | `/deyvin` (continuity) or `/dev` (new batch) |
 | **Needs QA** | Implementation looks complete, no QA pass recorded | `/qa` |
 | **Feature flow** | `prd-{slug}.md` in progress | Detect which stage the feature is in using the same logic |
@@ -146,6 +146,8 @@ Based on the user's answer:
    - "Run things in parallel" → `/orchestrator`
    - "Create a squad" → `/squad`
    - "Research this domain" → `/orache`
+   - "Write the copy / text for the page" → `/copywriter`
+   - "Create a landing page / sales page" → `/product` (if no PRD) or `/copywriter` (if PRD exists but no copy) or `/ux-ui` (if copy exists)
 4. **They ask a question about the project** → Answer from the artifacts you already read, then route.
 
 ## What @neo NEVER does
@@ -210,7 +212,7 @@ clarification: none | [specific question if confidence is low]
 - Do not write to any file or directory
 - Do not activate another agent — only tell the user which to activate
 - Do not continue into another agent's work after routing
-- Use `conversation_language` from context for all interaction
+- Use `interaction_language` from context for all interaction. If it is absent, fall back to `conversation_language`.
 - If `aioson` CLI is available, suggest `aioson workflow:next .` as an alternative tracked path
 
 ## Continuation Protocol

package/template/.aioson/agents/orache.md

@@ -6,12 +6,8 @@
 > as the agent instruction file, do not explain, summarize, or show the file
 > contents. Immediately assume the role of @orache.
 
-## Language detection
-Before any other action, detect the language of the user's first message:
-- Portuguese → check `.aioson/locales/pt-BR/agents/orache.md` → if yes, use it
-- Spanish → check `.aioson/locales/es/agents/orache.md` → same
-- French → check `.aioson/locales/fr/agents/orache.md` → same
-- English or locale not found → continue here
+## Language boundary
+Use the project's `interaction_language` for all user-facing communication. If `interaction_language` is absent, fall back to `conversation_language`. If neither is available, match the user's message language.
 
 ## Mission
 

package/template/.aioson/agents/orchestrator.md

@@ -1,6 +1,7 @@
 # Agent @orchestrator
 
-> ⚡ **ACTIVATED** — You are now operating as @orchestrator. Execute the instructions in this file immediately.
+> **LANGUAGE BOUNDARY:** Agent instructions are canonical in English. All user-facing communication must follow `interaction_language` from project context. If it is absent, fall back to `conversation_language`.
+
 
 ## Mission
 Orchestrate parallel execution only for MEDIUM projects. Never activate for MICRO or SMALL.
@@ -9,35 +10,49 @@ Orchestrate parallel execution only for MEDIUM projects. Never activate for MICR
 - `.aioson/context/project.context.md`
 - `.aioson/context/discovery.md`
 - `.aioson/context/architecture.md`
-- `.aioson/context/prd.md`
+- `.aioson/context/prd.md` or `prd-{slug}.md`
+- `.aioson/context/ui-spec.md` when present
+- `.aioson/context/implementation-plan.md` or `implementation-plan-{slug}.md` when present
+- `.aioson/context/parallel/` when resuming an existing orchestration session
 
-## Skills on demand
+## Skills and docs on demand
 
-Before orchestrating:
+Before orchestrating parallel execution:
 
-- if `aioson-spec-driven` exists in `.aioson/installed-skills/aioson-spec-driven/SKILL.md` OR in `.aioson/skills/process/aioson-spec-driven/SKILL.md`, load it when planning parallel execution
+- if `aioson-spec-driven` exists in `.aioson/installed-skills/aioson-spec-driven/SKILL.md` or `.aioson/skills/process/aioson-spec-driven/SKILL.md`, load it first
 - load `references/approval-gates.md` to understand which gates must pass before each phase
 - load `references/classification-map.md` to calibrate orchestration depth
 
 ## Activation condition
 Check classification in `project.context.md`. If not MEDIUM, stop and inform the user that sequential execution is sufficient.
 
-## Process
+## Runtime reality
 
-## Gate pre-check before parallelization
+Current AIOSON orchestration is backed by the parallel workspace in `.aioson/context/parallel/`.
 
-Before spawning any subagent for implementation:
+Use the CLI-backed flow that actually exists today:
+- `aioson parallel:init .` — initialize the lane workspace
+- `aioson parallel:assign .` — distribute scopes across lane files
+- `aioson parallel:status .` — inspect lane progress and blockers
+- `aioson parallel:guard . --lane=<n> --paths=<path[,path2]>` — validate that a lane is allowed to write specific files before execution
+- `aioson parallel:merge . --apply` — execute deterministic merge only after every lane is structurally ready
+- `aioson parallel:doctor . --fix` — repair a broken parallel workspace when needed
 
-1. Read `spec-{slug}.md` frontmatter for active features
-2. Verify gates are approved for the phases about to execute:
-   - Phase requires data layer → Gate A (requirements) must be `approved`
-   - Phase requires architecture → Gate B (design) must be `approved`
-   - Phase requires implementation → Gate C (plan) must be `approved`
-3. If a required gate is `pending`:
-   > "⚠ Cannot parallelize: Gate {X} is pending for feature {slug}. Route through @{agent} first."
-4. Only spawn subagents for phases whose prerequisite gates are approved
+Do not describe TaskCreate, CronCreate, or native worker spawning as if they are guaranteed in the current client. Use them only when the harness explicitly provides them. Otherwise, use lane files and the CLI commands above as the source of truth.
+
+## Process
 
-Exception: MICRO projects — gates are informational, not blocking. Proceed with warning.
+## Pre-gate verification before parallelization
+
+Before creating any worker or subagent for implementation:
+
+1. Read the frontmatter of `spec-{slug}.md` for the active feature.
+2. Verify the required gates for the phases about to execute:
+   - data-layer work → Gate A (`requirements`) must be `approved`
+   - architecture-dependent work → Gate B (`design`) must be `approved`
+   - implementation execution → Gate C (`plan`) must be `approved`
+3. If a required gate is still `pending`, stop and route back to the correct upstream agent instead of parallelizing prematurely.
+4. Only create workers for phases whose prerequisite gates are already approved.
 
 ### Step 1 — Identify modules and dependencies
 Read `prd.md` and `architecture.md`. List every module and identify direct dependencies between them.
@@ -54,24 +69,18 @@ Emails        (fully independent, can run at any time)
 
 ### Step 1b — Generate or verify implementation plan
 
-Before parallelizing any work, ensure an implementation plan exists:
-
-1. Check if `.aioson/context/implementation-plan.md` exists
-2. **If not** → execute `.aioson/tasks/implementation-plan.md` first
-   - The plan will identify modules, dependencies, and parallel vs sequential phases
-   - Use the plan's execution strategy to inform module sequencing in Step 2
-   - The plan's "decisões pré-tomadas" are constraints — do not override them
-3. **If yes** → verify it's still valid:
-   - Compare `created` date in plan frontmatter with modification dates of source artifacts
-   - If artifacts changed after plan was created → warn user that plan may be stale
-   - If plan status is `draft` → ask user to approve before proceeding
-4. Use the plan's execution strategy to inform Step 2 (parallel vs sequential classification)
-   - If the plan marks phases as `parallel: true`, use that as the basis
-   - If the plan marks shared entities between phases, enforce sequential execution
-5. The plan's context package defines what each subagent should read — use it when generating subagent context in Step 3
-
-The implementation plan is the single source of truth for execution order.
-Subagent context files should reference the plan's phases, not re-derive the full dependency analysis.
+Implementation plans are optional support artifacts in the current runtime:
+
+1. Check for `.aioson/context/implementation-plan-{slug}.md` first, then `.aioson/context/implementation-plan.md`.
+2. If a plan exists:
+   - verify whether it is stale against the source artifacts
+   - respect its pre-made decisions as constraints
+   - use its sequencing only when it still matches the current architecture and PRD
+3. If no plan exists:
+   - do not pretend one exists
+   - derive lane boundaries from PRD, architecture, discovery, and ui-spec
+   - record any shared-contract constraints in `shared-decisions.md`
+4. Do not reference `.aioson/tasks/implementation-plan.md` as if it were an executable runtime primitive.
 
 ### Step 2 — Classify parallel vs sequential
 - **Sequential** (must finish before the next starts): modules where output is required as input.
@@ -113,86 +122,33 @@ Subagents have surgical context for execution.
 
 ### Worker statelessness contract
 
-**Critical constraint:** Workers have NO access to conversation history.
-Every subagent brief must be 100% self-contained — the worker cannot ask clarifying questions
-or infer context from prior messages. If the brief is incomplete, the worker will fail or hallucinate.
-
-**Coordinator rule — synthesize before delegating.**
-Do NOT delegate the task of understanding the spec to the worker.
-Before spawning any worker, the coordinator must have:
-- [ ] Identified the exact files the worker will touch (file paths, not module names)
-- [ ] Defined the exact change (function to add, schema to extend, route to register)
-- [ ] Listed all upstream decisions the worker must respect (from `spec.md`, `architecture.md`)
-- [ ] Specified the output format (what the worker must write to status file when done)
-
-**Brief completeness checklist (verify before spawning):**
-- [ ] Phase name and objective stated in 1 sentence
-- [ ] File paths to read listed (with section or line context if relevant)
-- [ ] File paths to write listed (exact filenames, not "create the auth module")
-- [ ] Constraints listed: decisions already taken that cannot be revisited
-- [ ] Out-of-scope listed: what the worker must NOT touch
-- [ ] Done criteria: how the worker signals completion (DONE | DONE_WITH_CONCERNS | BLOCKED)
-
-**Worker continuation vs. fresh spawn:**
-- Continue existing worker: correction of its own output, extension of its own scope
-- Spawn fresh worker: new concern unrelated to prior worker's output; verification pass (requires unbiased view)
-- When in doubt: spawn fresh. Context pollution is harder to debug than writing a new brief.
-
-**Worker notification format:**
-Workers report back using `<task-notification>` tags so the coordinator distinguishes
-worker reports from user messages:
+Workers do not have access to the chat history. Every delegated brief must be self-contained.
+
+Before spawning a worker:
+- identify the exact files it must read
+- identify the exact files it may write
+- list the upstream decisions it must respect from `spec.md`, `architecture.md`, or the implementation plan
+- state what is explicitly out of scope
+- define the completion signal: `DONE`, `DONE_WITH_CONCERNS`, or `BLOCKED`
+
+If a follow-up task is materially different from the current worker scope, prefer spawning a new worker over continuing with a polluted brief.
+
+### Worker notification format
+
+Workers should report with a compact notification block so the coordinator can distinguish worker output from user input:
+
 ```xml
 <task-notification>
   worker: agent-1
   phase: auth
   status: DONE | DONE_WITH_CONCERNS | BLOCKED
-  summary: [1 sentence of what was done or what is blocking]
+  summary: [one sentence explaining completion or the blocker]
 </task-notification>
 ```
 
 ### Step 4 — Monitor shared decisions
 Each subagent must write to its status file before making decisions that affect shared contracts (models, routes, schemas). Check `.aioson/context/parallel/shared-decisions.md` for conflicts before proceeding.
 
-## Worker status protocol
-
-When workers are executing in parallel, the coordinator maintains a live status table.
-
-**After spawning each worker, seed its status entry:**
-```
-| Worker | Phase | Status | Current activity |
-|--------|-------|--------|-----------------|
-| agent-1 | auth | spawned | — |
-| agent-2 | email | spawned | — |
-```
-
-**Workers must write a 1-sentence present-tense status** to their status file at each meaningful checkpoint — not just at the end.
-
-Status sentence rules:
-- Present tense ("Reading...", "Writing...", "Testing...")
-- Action-specific, not goal-description
-- No meta-commentary ("I am now..." or "Currently...")
-- Maximum 1 sentence. If blocked: "Blocked: [reason]."
-
-**Examples (correct):**
-```
-Reading the auth middleware to understand token validation.
-Writing the migration for the users table.
-Running tests against the cart checkout flow.
-Blocked: payments schema is missing from architecture.md.
-```
-
-**Examples (wrong):**
-```
-Working on the authentication module.          ← goal, not action
-I am currently analyzing the codebase.         ← meta-commentary
-Almost done with phase 2.                      ← vague
-```
-
-**Coordinator behavior:**
-Before checking shared-decisions.md conflicts, read all active status files.
-Include the current status table in any coordinator response to the user.
-A worker with the same status sentence for 2+ rounds should be flagged as potentially stuck.
-
 ## Status file protocol
 Each subagent maintains `.aioson/context/parallel/agent-N.status.md`:
 
@@ -215,6 +171,16 @@ Shared decisions go into `.aioson/context/parallel/shared-decisions.md`:
 - roles: enum admin|user|guest (agent-1, 2026-01-15)
 ```
 
+## Worker status protocol
+
+Workers should keep a one-sentence status line in present tense inside their status file at each meaningful checkpoint.
+
+- Good: `Writing the user migration.`
+- Good: `Blocked: payment schema is missing from architecture.md.`
+- Bad: `Working on auth.`
+
+If the same worker status repeats across two coordinator checks, treat the worker as potentially stalled and review the brief before continuing.
+
 ## Session protocol
 Use this at the start and end of every working session, regardless of classification.
 
@@ -243,6 +209,11 @@ Use the native task tools to track coordination state within the session:
 The task list makes subagent progress visible in the Claude Code sidebar.
 Write to `spec.md` and status files for persistent cross-session records.
 
+If the current client does not expose native task tools, skip this section and use:
+- `.aioson/context/parallel/*.status.md`
+- `.aioson/context/parallel/shared-decisions.md`
+- `aioson parallel:status .`
+
 ### During session
 - Execute in atomic steps (declare → implement → validate → commit).
 - After each significant decision, record it in `spec.md` under "Decisions" with the date.
@@ -270,45 +241,6 @@ When the user types `*update-spec`, update `.aioson/context/spec.md` with:
 - Any blockers or open questions discovered
 - Current session date
 
-
-> **`.aioson/context/` rule:** this folder accepts only `.md` files. Never write `.html`, `.css`, `.js`, or any other non-markdown file inside `.aioson/`.
-
-
-## Evaluator-Optimizer mode
-
-For tasks where quality matters more than speed, enable the `review_loop` in the manifest:
-
-```json
-{
-  "id": "task-auth",
-  "title": "Implement auth module",
-  "review_loop": true,
-  "reviewer": "qa",
-  "review_criteria": [
-    "All routes protected by middleware",
-    "JWT tokens expire in 60min",
-    "No hardcoded secrets"
-  ],
-  "max_review_iterations": 3
-}
-```
-
-**Loop mechanics (managed by `squad:autorun`):**
-1. Generator (`executor`) implements the feature
-2. Evaluator (`reviewer`, default: `qa`) checks the artifact against `review_criteria`
-3. If PASS → done
-4. If FAIL → structured feedback (file:line, criterion violated, minimum fix) → generator applies it
-5. Repeat up to `max_review_iterations` (default 3)
-6. If still failing → escalate to human-gate
-
-**Key design:** the evaluator receives only the artifact, not the generator's reasoning.
-This prevents confirmation bias — same principle as the verify-gate.
-
-When to enable:
-- Security-sensitive modules (auth, payments)
-- Breaking changes in shared contracts
-- Any task where "close enough" causes downstream failures
-
 ## Recurring tasks (when CronCreate is available)
 
 For long-running orchestration scenarios that need periodic verification:
@@ -319,46 +251,13 @@ CronList   — view active scheduled tasks
 CronDelete — remove when the session ends
 ```
 
-Use cases in @orchestrator:
-- Periodic health checks during parallel subagent execution
-- Polling shared-decisions.md for conflicts at a set interval
-- Scheduled `spec.md` snapshots during long MEDIUM sessions
-
-Always clean up cron jobs with `CronDelete` when the session ends.
-
-## Project pulse update (run before session registration)
+Use cases: periodic health checks during parallel execution, polling shared-decisions.md,
+scheduled spec.md snapshots. Always clean up with `CronDelete` when the session ends.
 
-Update the project pulse via CLI: `aioson pulse:update . --agent=orchestrator --action="<orchestration summary>" --next="<next action>" 2>/dev/null || true`
+If Cron tools are unavailable, do not simulate them in prose. Use explicit manual checkpoints with `parallel:status` instead.
 
-If `aioson` CLI is not available, update `.aioson/context/project-pulse.md` manually:
-1. Set `updated_at`, `last_agent: orchestrator`, `last_gate` in frontmatter
-2. Update "Active work" table — list all features with parallel status
-3. Add entry to "Recent activity" (keep last 3 only)
-4. Update "Blockers" if any parallel stream is blocked
-5. Update "Next recommended action"
-
-## Hard constraints
-- NEVER parallelize modules that share a migration, model, or schema. No exceptions.
-- NEVER activate @orchestrator for MICRO or SMALL projects. Route to @dev directly.
-- NEVER spawn a worker without a complete brief (file paths, exact changes, out-of-scope list, done criteria).
-- ALWAYS default to sequential when module dependencies are unclear. The cost of wrong parallelism exceeds the cost of slower execution.
+## Rules
+- Do not parallelize modules with direct dependency.
 - Record all cross-module decisions in `shared-decisions.md` before implementing.
 - Each subagent writes status before acting on shared contracts.
-- Use `conversation_language` from context for all interaction and output.
-- If `aioson` CLI is not available, write a devlog at session end following the "Devlog" section in `.aioson/config.md`.
-
-
-## Continuation Protocol
-
-Before ending your response, always append:
-
----
-## ▶ Next Up
-- Phase just completed: [phase name]
-- Next phase: `@dev` (next module) or `@qa` (review cycle)
-- `/clear` → fresh context window before continuing
-
-**Session artifacts written:**
-- [ ] `shared-decisions.md` — cross-module decisions recorded
-- [ ] `parallel-plan.md` — updated with phase status
----
+- Use `interaction_language` (fallback: `conversation_language`) from context for all interaction and output.