@vpxa/aikit 0.1.74 → 0.1.76

package/scaffold/_preview/agents/_shared/researcher-base.md

@@ -1,114 +0,0 @@
-# Researcher — Shared Base Instructions
-
-> Shared methodology for all Researcher variants. Each variant's definition contains only its unique identity and model assignment. **Do not duplicate.**
-
-
-## MANDATORY FIRST ACTION
-
-Follow the **MANDATORY FIRST ACTION** and **Information Lookup Order** from code-agent-base:
-1. Run `status({})` — check Onboard Status and note the **Onboard Directory** path
-2. If onboard shows ❌ → Run `onboard({ path: "." })` and wait for completion
-3. If onboard shows ✅ → Read relevant onboard artifacts using `compact({ path: "<Onboard Directory>/<file>" })` before exploring
-
-**Start with pre-analyzed artifacts.** They cover 80%+ of common research needs.
-
----
-
-## Research Methodology
-
-### Phase 1: AI Kit Recall (BLOCKING)
-```
-search("task keywords")
-scope_map("what you need to investigate")
-```
-
-### Phase 2: Exploration
-- Use `graph`, `symbol`, `trace`, `find` for code exploration (graph FIRST for module relationships)
-- Use `graph({ action: 'neighbors' })` to understand cross-module dependencies before diving into symbol details
-- Use `file_summary`, `compact` for efficient file reading
-- Use `analyze_structure`, `analyze_dependencies` for package-level understanding
-- Use `web_search`, `web_fetch` for external documentation
-
-### Phase 3: Synthesis
-- Combine findings from multiple sources using `digest`
-- Create `stratum_card` for key files that will be referenced later
-- Build a coherent picture of the subsystem
-
-### Phase 4: Report
-Return structured findings. Always include:
-1. **Summary** — 1-3 sentence overview
-2. **Key Findings** — Bullet list of important discoveries
-3. **Files Examined** — Paths with brief purpose notes
-4. **Recommendation** — Your suggested approach with reasoning
-5. **Trade-offs** — Pros and cons of alternatives
-6. **Risks** — What could go wrong
-
-### Phase 5: MANDATORY — Persist Discoveries
-
-**Before returning your report**, you MUST call `remember()` for:
-- ✅ Architecture insights not already in onboard artifacts
-- ✅ Non-obvious findings, gotchas, or edge cases
-- ✅ Trade-off analysis and recommendations made
-- ✅ External knowledge gathered from web_search/web_fetch
-
-```
-remember({
-  title: "Short descriptive title",
-  content: "Detailed finding with context",
-  category: "patterns" | "conventions" | "decisions" | "troubleshooting"
-})
-```
-
-**If you complete research without remembering anything, you wasted tokens.** Your research should enrich the knowledge base for future sessions.
-
----
-
-## FORGE-Aware Research
-
-When investigating tasks that involve code changes (architecture decisions, design analysis, subsystem investigation):
-
-1. **Classify** — Run `forge_classify({ task, files, root_path })` to determine the complexity tier
-2. **Track findings** (Standard+) — Use `evidence_map` to record critical findings as verified claims with receipts
-3. **Flag risks** — If research reveals security, contract, or cross-boundary concerns, note the FORGE tier upgrade implications
-4. **Report tier recommendation** — Include FORGE tier and triggers in your research report
-
-This ensures the Orchestrator and Planner have tier context when planning implementation.
-
----
-
-## Multi-Model Decision Context
-
-When invoked for a decision analysis, you receive a specific question. You MUST:
-1. **Commit to a recommendation** — do not hedge with "it depends"
-2. **Provide concrete reasoning** — cite specific files, patterns, or constraints
-3. **Acknowledge trade-offs** — show you considered alternatives
-4. **State your confidence level** — high/medium/low with reasoning
-
----
-
-## Invocation Mode Detection
-
-- **Direct** (has AI Kit tools) → Follow the **Information Lookup Order** from code-agent-base
-- **Sub-agent** (prompt has "## Prior AI Kit Context") → Skip AI Kit Recall, use provided context
-
----
-
-## Context Efficiency
-
-- **NEVER use `read_file` to understand code** — use AI Kit compression tools instead
-- **`file_summary`** for structure (exports, imports, call edges — 10x fewer tokens)
-- **`compact`** for specific sections (5-20x token reduction vs read_file)
-- **`digest`** when synthesizing from 3+ sources
-- **`stratum_card`** for files you'll reference repeatedly
-- **`read_file` is ONLY acceptable** when you need exact lines for a pending edit operation
-
-## Parallel Exploration via `lane`
-
-For questions that require trying approach A vs approach B in isolation:
-1. `lane({ action:'create', name:'approach-a' })` — isolated file copies
-2. Apply approach A mentally; record observations
-3. `lane({ action:'create', name:'approach-b' })` — second isolate
-4. Apply approach B mentally; record observations
-5. `lane({ action:'diff', names:['approach-a','approach-b'] })` — compare
-6. Include the diff summary in your output; do NOT merge lanes back (read-only role)
-

package/scaffold/_preview/agents/templates/adr-template.md

@@ -1,28 +0,0 @@
-# DR-NNN: {Short Title}
-
-**Status:** Proposed | Accepted | Rejected | Deprecated | Superseded
-**Date:** YYYY-MM-DD
-**Participants:** {which Researcher variants participated}
-
-## Context
-{What is the issue? Why are we making this decision?}
-{If superseding, link: "Supersedes DR-NNN."}
-
-## Decision
-{What was decided and why — 2-5 sentences max}
-
-## Decision Analysis Summary
-| Model | Recommendation | Key Reasoning |
-|-------|---------------|---------------|
-
-**Agreements:** {what 3+ models agreed on}
-**Disagreements:** {where they diverged}
-
-## Consequences
-**Positive:** {benefits}
-**Negative:** {trade-offs accepted}
-**Risks:** {what could go wrong, and any mitigations}
-
-## Alternatives Considered
-{Other approaches evaluated and why they were rejected — keeps the "why not" alongside the "why"}
-

package/scaffold/_preview/agents/templates/execution-state.md

@@ -1,26 +0,0 @@
-# Execution State: {Task Title}
-
-**Status:** PLANNING | IN_PROGRESS | REVIEW | COMPLETED | BLOCKED
-**Started:** {timestamp}
-**Plan:** {link to plan file}
-
-## Phases
-
-| # | Title | Agent | Status | Batch |
-|---|-------|-------|--------|-------|
-
-## Current Batch
-
-**Batch {N}:** {phases in this batch}
-**Status:** IMPLEMENTING | REVIEWING | APPROVED
-
-## Decisions Log
-
-| Decision | Rationale | ADR |
-|----------|-----------|-----|
-
-## Blockers
-
-| Issue | Severity | Assigned |
-|-------|----------|----------|
-

package/scaffold/_preview/flows/_epilogue/steps/docs-sync/README.md

@@ -1,120 +0,0 @@
-# Epilogue: Documentation Sync
-
-> **This is a mandatory epilogue step.** It runs automatically after every flow completes to keep project documentation synchronized with code changes.
-
-## Objective
-
-Review the changes made during this flow and update the `docs/` folder using AI Kit analysis tools — never write docs from scratch when a tool can generate the foundation.
-
-## Prerequisites
-
-Load the `docs` skill before proceeding — it contains the full documentation convention, templates, architecture blueprint workflow, and change-to-doc mapping rules.
-
-## Instructions
-
-### 0. Gather Flow Artifacts
-
-Read all artifacts produced during this flow — they contain design decisions, requirements, and verification results that are the most valuable documentation input.
-
-```
-flow_status()                                           # Get artifactsPath
-find({ pattern: "*.md", path: "{{artifacts_path}}" })   # Discover all flow artifacts
-digest({ sources: [                                     # Compress artifacts for context
-  { path: "<found-artifact-1>" },
-  { path: "<found-artifact-2>" },
-  ...
-]})
-```
-
-Map each discovered artifact to documentation actions using the artifact-to-doc mapping from the `docs` skill. Different flows produce different artifacts — read everything `find()` returns and focus on content that contains decisions, requirements, and verification results.
-
-If no artifacts exist, proceed to Step 1 in source-only mode.
-
-### 1. Assess Changes (tool-driven)
-
-```
-git_context({})                                         # What changed in this flow
-blast_radius({ changed_files: ["<changed-files>"] })    # Impact analysis — which modules affected
-```
-
-Use the output to classify changes:
-
-| Change Signal | Documentation Action |
-|---------------|---------------------|
-| New files in `src/` | Potential new component doc |
-| Modified API surface | Update reference docs |
-| New package or module boundary | Update architecture overview |
-| Architecture decision made | Delegate to `adr-skill` |
-| Test-only or config-only changes | Likely skip |
-
-### 2. Apply the Change-to-Doc Mapping
-
-Follow the decision tree from the `docs` skill to determine which documentation actions are needed.
-
-### 3. Bootstrap `docs/` If Needed (full tool-driven workflow)
-
-If `docs/` doesn't exist, run the **Architecture Blueprint Workflow** from the `docs` skill:
-
-```
-# Step 1: Generate content with AI Kit tools
-produce_knowledge({ path: "." })                        # → Foundation for docs/README.md
-analyze_structure({ path: "." })                        # → docs/architecture/overview.md structure
-analyze_diagram({ path: "." })                          # → docs/architecture/ Mermaid diagrams
-analyze_dependencies({ path: "." })                     # → docs/architecture/overview.md deps section
-analyze_entry_points({ path: "." })                     # → docs/reference/api.md foundation
-analyze_patterns({ path: "." })                         # → docs/architecture/overview.md patterns
-
-# Step 2: Create the docs/ tree from tool outputs
-docs/
-├── README.md              ← From produce_knowledge + project context
-├── architecture/
-│   ├── overview.md        ← From analyze_structure + analyze_dependencies + analyze_diagram
-│   └── components/        ← From analyze_symbols per major component
-├── decisions/
-│   └── index.md           ← ADR log (delegate to adr-skill)
-├── guides/
-│   └── testing.md         ← From analyze_patterns test info
-└── reference/
-    └── api.md             ← From analyze_entry_points
-```
-
-Use the Architecture Blueprint sections from the `docs` skill as the template for each document.
-
-### 4. Update Existing Docs (tool-assisted)
-
-When `docs/` already exists:
-
-```
-compact({ path: "docs/architecture/overview.md", query: "section to update" })  # Read target section
-blast_radius({ changed_files: ["<files>"] })                                     # What's affected
-```
-
-- **Don't rewrite** — update the relevant sections of existing docs
-- **Don't duplicate** — if the information is in code comments or READMEs, reference it
-- Use `compact` to read existing doc sections before editing
-- Use `blast_radius` output to determine which sections need updating
-
-### 5. Delegate When Appropriate
-
-- Architecture decisions → `adr-skill` → `docs/decisions/`
-- Architecture diagrams → `c4-architecture` skill → `docs/architecture/`
-- Full architecture refresh → Run the Architecture Blueprint Workflow from `docs` skill
-
-### 6. Update Index
-
-If documents were added, removed, or renamed, update `docs/README.md` to reflect the current structure.
-
-### 7. Skip If Nothing Changed
-
-If the flow's changes don't warrant doc updates (e.g., pure bug fix with no revelations), report:
-- "No documentation updates needed"
-- Reason: (brief explanation)
-
-## Completion Criteria
-
-- [ ] `git_context` + `blast_radius` used to assess changes
-- [ ] Change-to-doc mapping applied from `docs` skill
-- [ ] `docs/` bootstrapped with tool outputs if it didn't exist
-- [ ] Relevant docs created or updated (or skipped with reason)
-- [ ] `docs/README.md` index is current
-- [ ] No placeholder/empty docs created — all content tool-generated or hand-written with purpose

package/scaffold/_preview/flows/aikit-advanced/README.md

@@ -1,70 +0,0 @@
-# aikit:advanced — Full Development Flow
-
-Full development flow for **new features, API design, and architecture changes**.
-
-## Steps
-
-| # | Step | Skill | Produces | Requires | Agents |
-|---|------|-------|----------|----------|--------|
-| 1 | **Design Gate** | `steps/design/README.md` | `design-decisions.md` | — | Researcher-Alpha/Beta/Gamma/Delta |
-| 2 | **Specification** | `steps/spec/README.md` | `spec.md` | `design-decisions.md` | Researcher-Alpha |
-| 3 | **Planning** | `steps/plan/README.md` | `plan.md` | `spec.md` | Planner, Explorer |
-| 4 | **Task Breakdown** | `steps/task/README.md` | `tasks.md` | `plan.md` | Planner, Architect-Reviewer-Alpha |
-| 5 | **Execution** | `steps/execute/README.md` | `progress.md` | `tasks.md` | Orchestrator, Implementer, Frontend, Refactor |
-| 6 | **Verification** | `steps/verify/README.md` | `verify-report.md` | `progress.md` | Code-Reviewer-Alpha/Beta, Architect-Reviewer-Alpha/Beta, Security |
-
-## How It Works
-
-Each step has a **README.md** file that contains the detailed instructions for the agent(s) executing that step. The Orchestrator reads the README.md via `flow_read_instruction` and delegates work accordingly.
-
-### Step 1: Design Gate
-- Full brainstorming session for new features and architectural changes
-- FORGE classification (`forge_classify`) + grounding (`forge_ground`) for complex tasks
-- Parallel 4-researcher decision protocol for non-trivial technical decisions
-- ADR generation for critical-tier tasks
-- **Mandatory user stop** before proceeding — design decisions must be approved
-- Read `steps/design/README.md` for the full protocol
-
-### Step 2: Specification
-- Elicit requirements from the user, clarify scope
-- Define acceptance criteria and constraints
-- Build on design decisions from the previous step
-
-### Step 3: Planning
-- Deep codebase analysis using `search`, `scope_map`, `trace`, `analyze_*`
-- Design architecture based on spec and design decisions
-- Create comprehensive implementation plan with file-level changes
-
-### Step 4: Task Breakdown
-- Break the plan into ordered, atomic implementation tasks
-- Define dependencies between tasks
-- Identify parallel batches for multi-agent execution
-- Architecture review of the task structure
-
-### Step 5: Execution
-- Orchestrator dispatches agents in parallel batches per the task breakdown
-- Each agent gets a scoped task (1-3 files) with clear acceptance criteria
-- TDD: write tests first, then implement
-- Per-batch review cycle: Code Review (dual) → Arch Review → Security → Evidence Gate
-
-### Step 6: Verification
-- Dual code review (Code-Reviewer-Alpha + Beta)
-- Architecture review (Architect-Reviewer-Alpha + Beta)
-- Security review
-- Run `check({})` + `test_run({})` + `blast_radius({})`
-- `evidence_map({ action: "gate" })` for final quality gate
-
-## Using Skills Inside Steps
-
-When the Orchestrator activates a step:
-
-1. **Read the instruction first** — `flow_read_instruction` returns the README.md for the current step
-2. **Follow step instructions** — the README.md is the primary guide for what to do
-3. **Delegate to listed agents** — each step lists which agents are appropriate
-4. **Produce the required artifact** — the step's `produces` field specifies what file to create in the artifacts directory
-5. **Check dependencies** — the step's `requires` field lists artifacts from previous steps that must exist
-6. **Report status** — agents report `DONE` | `DONE_WITH_CONCERNS` | `NEEDS_CONTEXT` | `BLOCKED` to the Orchestrator
-
-## Artifacts
-
-All artifacts are stored in the run directory under .flows/{topic}/. The template variable `{{artifacts_path}}` resolves to the actual path at runtime.

package/scaffold/_preview/flows/aikit-advanced/steps/design/README.md

@@ -1,178 +0,0 @@
-# Design Gate — Advanced Flow
-
-Full design gate for new features, API design, and architecture changes. Runs brainstorming, decision protocol, and FORGE classification before specification begins.
-
-## When This Step Runs
-
-This is the **first step** of the `aikit:advanced` flow. It runs before specification.
-
-## Instructions
-
-### 1. Task Classification
-
-Classify the task:
-
-| Category | Indicators | Action |
-|----------|-----------|--------|
-| **Bug fix** | Error, regression, "fix" — wrong flow, should use `aikit:basic` | → Note mismatch, still run Quick Design |
-| **New feature** | New behavior, new API, new component | → Run **Full Design** below |
-| **Architecture change** | Restructure, migration, new pattern, cross-cutting | → Run **Full Design** with architecture focus |
-
-### 2. FORGE Classification
-
-Run `forge_classify({ task: "<task description>", files: [<relevant files>] })` to determine the complexity tier.
-
-| Tier | Meaning | Design Depth |
-|------|---------|-------------|
-| **Floor** | Low risk, well-understood | Quick brainstorm, 1-2 decisions |
-| **Standard** | Moderate complexity | Full brainstorm, parallel research, decision protocol |
-| **Critical** | High risk, contract/security implications | Deep brainstorm, 4-researcher parallel review, ADR required |
-
-### 3. Brainstorming Session
-
-Load the `brainstorming` skill and conduct a structured brainstorming session:
-
-1. **Intent Discovery** — What is the user trying to achieve? What problem does this solve?
-2. **Constraint Mapping** — Technical constraints, time constraints, compatibility requirements
-3. **Approach Exploration** — Generate 2-4 possible approaches
-4. **Trade-off Analysis** — Compare approaches on: complexity, maintainability, performance, risk
-
-For **Critical** tier tasks, also explore:
-- Security implications
-- Backward compatibility
-- Migration path
-- Rollback strategy
-
-### 4. Decision Protocol (Standard & Critical tiers)
-
-When technical decisions need resolution:
-
-1. **Identify decisions** — List each decision point with 2+ viable options
-2. **Parallel research** — Delegate to Researcher agents (2 for Standard, 4 for Critical):
-   - Researcher-Alpha: Deep analysis of primary approach
-   - Researcher-Beta: Trade-offs and edge cases of alternatives
-   - Researcher-Gamma: Cross-domain patterns and precedents
-   - Researcher-Delta: Feasibility and performance implications
-3. **Synthesize** — Combine researcher findings into a recommendation per decision
-4. **ADR** (Critical tier) — Load `adr-skill` and create an Architecture Decision Record
-
-### 5. FORGE Ground (Standard & Critical tiers)
-
-Run `forge_ground({ task, root_path: "." })` to:
-- Scope the affected files and modules
-- Identify unknowns and risks
-- Load existing constraints and conventions
-
-**Auto-upgrade check**: If `forge_ground` reveals contract-type unknowns or security concerns not caught by initial `forge_classify`, recommend tier upgrade.
-
-### 6. Write `{{artifacts_path}}/design-decisions.md` to disk
-
-**You MUST create this file on disk** using `create_file` or equivalent — do not just present content in chat.
-
-```markdown
-## Design Decisions
-
-### FORGE Assessment
-- **Tier**: {Floor | Standard | Critical}
-- **Rationale**: {why this tier}
-- **Auto-upgrade**: {yes/no — if yes, explain}
-
-### Task Summary
-- **Goal**: {what we're building}
-- **Problem**: {what problem this solves}
-- **Users affected**: {who is impacted}
-
-### Approach
-- **Chosen approach**: {description}
-- **Alternatives considered**: {list with reasons for rejection}
-
-### Key Decisions
-| # | Decision | Choice | Rationale |
-|---|----------|--------|-----------|
-| 1 | {decision} | {choice} | {why} |
-
-### Constraints
-- {constraint 1}
-- {constraint 2}
-
-### Risks
-| Risk | Likelihood | Impact | Mitigation |
-|------|-----------|--------|------------|
-| {risk} | {L/M/H} | {L/M/H} | {mitigation} |
-
-### Open Questions
-- {question 1}
-- {question 2}
-```
-
-### 7. Present to User
-
-Use `present({ format: "html" })` (or `format: "browser"` in CLI mode) to show:
-- Design decisions summary
-- FORGE tier and rationale
-- Key trade-offs
-- Open questions requiring user input
-
-**🛑 MANDATORY STOP** — Wait for user approval of design decisions before proceeding.
-
-### 8. Report to Orchestrator
-
-After user approves:
-- `DONE` — design decisions approved, ready for specification
-- `DONE_WITH_CONCERNS` — approved with caveats (list them)
-- `NEEDS_CONTEXT` — user raised questions that need more research
-
-**Do NOT call `flow_step`** — let the Orchestrator advance the flow.
-
-## Outputs
-
-Write `{{artifacts_path}}/design-decisions.md` to disk. **You MUST create this file** using `create_file` or equivalent — do not just present content in chat. This file is a prerequisite for the next step.
-
-## Produces
-
-- `{{artifacts_path}}/design-decisions.md` — FORGE tier, approach, key decisions, constraints, risks
-
-## Agents
-
-- `Researcher-Alpha` — Deep analysis of primary approach
-- `Researcher-Beta` — Trade-offs and edge cases
-- `Researcher-Gamma` — Cross-domain patterns
-- `Researcher-Delta` — Feasibility and performance
-
-## Foundation Integration
-
-Load these skills BEFORE executing this step:
-
-| Skill | Purpose | When |
-|-------|---------|------|
-| `aikit` | Core MCP tools — search, analyze, remember, validate | Always (auto-loaded) |
-| `present` | Rich rendering for any structured output — assessments, reports, comparisons, reviews, status boards, tables, charts, and all artifact content | Use for ANY output that benefits from rich rendering, not just dashboards |
-| `multi-agents-development` | Dispatch templates, task decomposition, review pipeline patterns | Before dispatching any subagent |
-| `brainstorming` | Structured ideation for design/creative decisions | Before any design choice or new feature exploration |
-| `c4-architecture` | C4 model diagrams showing system structure changes | When visualizing proposed architecture |
-| `adr-skill` | Architecture Decision Records for non-trivial decisions | Critical tier — document architecture decisions |
-
-### Presentation Rules
-- Use `present` for **any output** that benefits from rich rendering — not limited to dashboards
-- Assessments, reports, comparisons, reviews, status boards → `present({ format: "html" })`
-- Tables, charts, progress tracking, code review findings → always present
-- Artifact content and summaries → present with structured layout
-- Only use plain text for brief confirmations and simple questions
-
-## Completion Criteria
-
-- [ ] `{{artifacts_path}}/design-decisions.md` written to disk (NOT just presented in chat)
-- [ ] FORGE tier determined and documented
-- [ ] Brainstorming session completed (for Standard+ tier)
-- [ ] Key design decisions documented with rationale
-- [ ] User approval received (🛑 MANDATORY STOP)
-
-## Knowledge Capture
-
-Before completing this step, persist important findings using `remember()`:
-
-- **Design decisions**: Chosen approach and alternatives considered with trade-offs
-- **Architecture patterns**: New patterns introduced or existing patterns that must be followed
-- **Constraints discovered**: Technical limitations, compatibility requirements, or performance boundaries
-
-**Every step produces knowledge worth preserving.** If you discovered something that would help a future session, call `remember()` now.

package/scaffold/_preview/flows/aikit-advanced/steps/execute/README.md

@@ -1,145 +0,0 @@
----
-name: execute
-description: Implement all tasks from the task breakdown, dispatching agents in parallel where possible.
----
-
-# Execution
-
-## Prerequisites Check
-
-Before starting this step, verify:
-- [ ] Task breakdown approved with valid task graph
-- [ ] `{{artifacts_path}}/tasks.md` exists with defined batches and dependencies
-
-If prerequisites are NOT met -> **backtrack to task step** (`flow_step({ action: 'redo' })` on previous step)
-
-## Purpose
-
-Execute all tasks from the breakdown, dispatching implementation agents in batches for maximum parallelism while maintaining correctness.
-
-## Inputs
-
-- `{{artifacts_path}}/tasks.md` — the atomic task list with dependencies and agent assignments
-
-## Process
-
-1. **Load tasks** — Read task graph, dependencies, and parallelism map
-2. **Execute by batch** — For each batch in the parallelism map:
-   a. Dispatch assigned agents in parallel (different files = safe parallelism)
-   b. Each agent receives: task scope, affected files, acceptance criteria, relevant code context via `compact()`/`digest()`
-   c. Wait for all agents in batch to complete
-   d. Run `check({})` + `test_run({})` after each batch
-   e. Fix any failures before proceeding to next batch
-3. **Track progress** — Update task checkboxes as each completes
-4. **Handle failures** — If an agent reports `BLOCKED` or `NEEDS_CONTEXT`:
-   - Max 2 retries per task with refined context
-   - If still blocked, escalate to user
-5. **Final validation** — After all batches: `check({})` + `test_run({})` must pass
-
-## Outputs
-
-Write `{{artifacts_path}}/progress.md` to disk. **You MUST create this file** using `create_file` or equivalent — do not just present content in chat.
-
-Template:
-
-```markdown
-# Execution Progress: <feature title>
-
-## Task Status
-- [x] T1.1: <description> — DONE
-- [x] T1.2: <description> — DONE
-- [x] T2.1: <description> — DONE
-- [ ] T2.2: <description> — IN PROGRESS
-...
-
-## Changes Made
-| File | Change | Task |
-|------|--------|------|
-| <file> | <description> | T1.1 |
-| ... | ... | ... |
-
-## Tests Added/Modified
-<list of test files and what they cover>
-
-## Validation
-- check: PASS/FAIL
-- test_run: PASS/FAIL (<N> passed, <M> failed)
-
-## Deviations
-<any changes from the task plan and why>
-
-## Blocked Items
-<items that needed user intervention, if any>
-```
-
-## Agents
-
-| Agent | Role |
-|-------|------|
-| **Orchestrator** | Coordinates batch execution, handles failures and retries |
-| **Implementer** | Primary code writer for backend, logic, and infrastructure tasks |
-| **Frontend** | UI/UX implementation for React components, styling, responsive design |
-| **Refactor** | Code cleanup, restructuring, and pattern alignment tasks |
-
-**Parallelism rules**:
-- Read-only agents: unlimited parallelism
-- File-modifying agents: parallel ONLY on completely different files
-- Max 4 concurrent file-modifying agents
-
-## Foundation Integration
-
-Load these skills BEFORE executing this step:
-
-| Skill | Purpose | When |
-|-------|---------|------|
-| `aikit` | Core MCP tools — search, analyze, remember, validate | Always (auto-loaded) |
-| `present` | Rich rendering for any structured output — assessments, reports, comparisons, reviews, status boards, tables, charts, and all artifact content | Use for ANY output that benefits from rich rendering, not just dashboards |
-| `multi-agents-development` | Dispatch templates, task decomposition, review pipeline patterns | Before dispatching any subagent |
-| `brainstorming` | Structured ideation for design/creative decisions | Before any design choice or new feature exploration |
-| `session-handoff` | Context preservation for long-running execution phases | When execution spans multiple sessions or context is filling |
-
-### Presentation Rules
-- Use `present` for **any output** that benefits from rich rendering — not limited to dashboards
-- Assessments, reports, comparisons, reviews, status boards → `present({ format: "html" })`
-- Tables, charts, progress tracking, code review findings → always present
-- Artifact content and summaries → present with structured layout
-- Only use plain text for brief confirmations and simple questions
-
-### Orchestrator Dispatch Protocol
-
-Follow the `multi-agents-development` skill patterns for dispatch:
-
-1. **Independence Check** before parallelizing:
-   - Same files? → sequential
-   - Shared mutable state? → sequential
-   - Execution-order dependent? → sequential
-   - Need shared new types? → define contract first, then parallel
-   - All clear? → **parallel dispatch**
-
-2. **Subagent Context Template** (each dispatch includes):
-   - **Scope**: exact files + boundary (do NOT touch)
-   - **Goal**: acceptance criteria, testable
-   - **Arch Context**: actual code snippets via `compact()`/`digest()`
-   - **Constraints**: patterns, conventions, anti-patterns
-   - **Self-Review**: checklist before declaring DONE
-
-3. **Status Protocol**: `DONE` | `DONE_WITH_CONCERNS` | `NEEDS_CONTEXT` | `BLOCKED`
-4. **Max 2 retries** per task — then escalate to user
-
-## Completion Criteria
-
-- [ ] All tasks marked completed
-- [ ] `check({})` passes
-- [ ] `test_run({})` passes
-- [ ] No blocked items remaining
-- [ ] `{{artifacts_path}}/progress.md` written
-
-## Knowledge Capture
-
-Before completing this step, persist important findings using `remember()`:
-
-- **Implementation decisions**: Why specific approaches were chosen over alternatives
-- **Patterns established**: New conventions or patterns that future code should follow
-- **Gotchas encountered**: Edge cases, workarounds, or non-obvious behaviors discovered during execution
-
-**Every step produces knowledge worth preserving.** If you discovered something that would help a future session, call `remember()` now.