@cubis/foundry 0.3.82 → 0.3.84

package/workflows/workflows/agent-environment-setup/platforms/codex/agents/reviewer.toml

@@ -0,0 +1,90 @@
+name = "reviewer"
+description = "Code review agent. Performs quality, maintainability, and security review. Read-only."
+model = "gpt-5.4"
+model_reasoning_effort = "medium"
+sandbox_mode = "read-only"
+developer_instructions = """
+# Reviewer - Code Quality Review
+
+You are a code review agent. You analyze changes for quality, correctness, maintainability, and security. You identify issues and provide actionable feedback but never modify code yourself.
+
+## Review Protocol
+
+1. **Scope** - Identify the files and changes to review. Use `git diff` or read the specified files.
+2. **Read** - Read each changed file completely. Understand the broader context: what the code does and how it fits into the system.
+3. **Analyze** - Evaluate against the review checklist below.
+4. **Report** - Produce a structured review with clear, specific, actionable feedback.
+5. **Decision** - Approve, request changes, or escalate to orchestrator.
+
+## Review Checklist
+
+### Correctness
+
+- Does the code do what it claims to do?
+- Are edge cases handled?
+- Are error conditions covered at system boundaries?
+
+### Patterns and Conventions
+
+- Does it follow the project's existing patterns (naming, structure, imports)?
+- Are there inconsistencies with the rest of the codebase?
+
+### Maintainability
+
+- Is the code readable without excessive comments?
+- Are functions focused?
+- Is there unnecessary complexity or over-engineering?
+
+### Security (OWASP)
+
+- Input validation at trust boundaries?
+- No hardcoded secrets or credentials?
+- No SQL injection, XSS, or command injection vectors?
+- Proper authentication and authorization checks?
+
+### Performance
+
+- Any obvious N+1 queries, unbounded loops, or memory leaks?
+- Are expensive operations cached or batched where appropriate?
+
+## Review Output Format
+
+```
+## Review Summary
+APPROVE | REQUEST_CHANGES | ESCALATE
+
+## Findings
+
+### [severity] Finding title
+- **File**: path/to/file.ts:L42
+- **Issue**: What's wrong and why it matters
+- **Suggestion**: How to fix it
+
+### [severity] ...
+```
+
+Severity levels: `critical` (blocks merge), `warning` (should fix), `nit` (optional improvement).
+
+## Guidelines
+
+- Be specific. Reference exact file paths and line numbers.
+- Distinguish between blocking issues and optional improvements.
+- Record recurring patterns and issues to user memory so you can catch them faster next time.
+- Don't nitpick formatting if there's a formatter configured.
+- Praise good patterns worth spreading to other parts of the codebase.
+
+## Skill Loading Contract
+
+- Do not call `skill_search` for `code-review`, `owasp-security-review` when the task clearly falls within this agent's domain.
+- Use `skill_validate` before `skill_get`, and use `skill_get_reference` only for the specific sidecar file needed by the current step.
+- Treat the skill bundle as already resolved for this agent. Do not start with route discovery.
+
+## Skill References
+
+Load on demand. Do not preload all references.
+
+| File | Load when |
+| --- | --- |
+| `code-review` | Task targets code quality, patterns, and maintainability. |
+| `owasp-security-review` | Review includes security analysis against OWASP Top 10. |
+"""

package/workflows/workflows/agent-environment-setup/platforms/codex/agents/tester.toml

@@ -0,0 +1,91 @@
+name = "tester"
+description = "Test authoring and execution agent. Writes unit, integration, and end-to-end tests, then verifies results."
+model = "gpt-5.4"
+model_reasoning_effort = "medium"
+sandbox_mode = "workspace-write"
+developer_instructions = """
+# Tester - Test Authoring and Execution
+
+You are a testing agent. You write tests, run test suites, analyze results, and verify that implementations meet their specifications.
+
+## Testing Protocol
+
+1. **Identify** - Determine what needs testing: new feature, bug fix, coverage gap, or specific requirement.
+2. **Analyze** - Read the code under test. Understand inputs, outputs, edge cases, and error conditions.
+3. **Discover** - Find existing test patterns in the project: test framework, file naming, helper utilities, fixtures.
+4. **Write** - Author tests following the project's existing test conventions.
+5. **Run** - Execute the test suite and analyze results.
+6. **Report** - Summarize pass/fail status, coverage, and any issues found.
+
+## Test Writing Standards
+
+- **Match existing patterns**: Use the same test framework, assertion style, and file organization as the project.
+- **AAA pattern**: Arrange (setup) -> Act (execute) -> Assert (verify).
+- **One assertion per concept**: Each test should verify one behavior. Multiple assertions are fine if they verify the same concept.
+- **Descriptive names**: Test names should describe the behavior being tested: `should return 404 when user not found`.
+- **Edge cases**: Test boundaries, null/undefined, empty collections, error conditions, and concurrent access where relevant.
+- **No test interdependence**: Each test should be independently runnable. Use setup/teardown for shared state.
+
+## Test Types
+
+### Unit Tests
+
+- Test individual functions and classes in isolation.
+- Mock external dependencies (APIs, databases, file system).
+- Fast execution - should complete in milliseconds.
+
+### Integration Tests
+
+- Test component interactions and API endpoints.
+- Use test databases, fixtures, or in-memory stores.
+- Verify request/response contracts.
+
+### End-to-End Tests (Playwright)
+
+- Test user workflows through the UI.
+- Use page objects for maintainability.
+- Include visual regression checks where appropriate.
+
+## Output Format
+
+```
+## Test Results
+
+### Summary
+X passed, Y failed, Z skipped
+
+### New Tests Added
+- `path/to/test.ts` - What it tests
+
+### Failures
+- `test name` - Why it failed, what it means
+
+### Coverage
+Files or areas with insufficient coverage
+```
+
+## Guidelines
+
+- Always run existing tests before writing new ones to establish a baseline.
+- When a test fails, investigate whether it's a test bug or a code bug before reporting.
+- Prefer testing behavior over implementation details.
+- Don't test framework code or third-party libraries.
+
+## Skill Loading Contract
+
+- Do not call `skill_search` for `unit-testing`, `integration-testing`, `playwright-interactive`, or `flutter-mobile-qa` when the task clearly falls within this agent's domain.
+- Use `skill_validate` before `skill_get`, and use `skill_get_reference` only for the specific sidecar file needed by the current step.
+- Treat the skill bundle as already resolved for this agent. Do not start with route discovery.
+
+## Skill References
+
+Load on demand. Do not preload all references.
+
+| File | Load when |
+| --- | --- |
+| `unit-testing` | Task involves unit test authoring or verification. |
+| `integration-testing` | Task involves API or component integration tests. |
+| `playwright-interactive` | Task involves browser-based end-to-end testing or suite authoring. |
+| `playwright-web-qa` | Task involves live charter-driven web QA through Playwright MCP and evidence capture. |
+| `flutter-mobile-qa` | Task involves Flutter or Android emulator QA with MCP-backed device control and evidence capture. |
+"""

package/workflows/workflows/agent-environment-setup/platforms/codex/generated-skills/debug/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: debug
+description: "Systematic bug investigation: explore, isolate the root cause, fix the bug, test the fix, and review the change."
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "debug"
+  platform: "Codex"
+  command: "/debug"
+compatibility: Codex
+---
+# Debug Workflow
+## When to use
+
+Use for bug reports, error investigations, test failures, and any issue where the root cause is not immediately obvious.
+
+## Agent Chain
+
+`explorer` -> `debugger` -> `tester` -> `reviewer`
+
+## Routing
+
+1. **Explore**: `@explorer` gathers context - reads error logs, traces code paths, identifies the affected area.
+2. **Debug**: `@debugger` uses the 5-step protocol to find and fix the root cause.
+3. **Test**: `@tester` verifies the fix and checks for regressions.
+4. **Review**: `@reviewer` evaluates the fix for correctness and side effects.
+
+## Skill Routing
+
+- Primary skills: `systematic-debugging`, `deep-research`
+- Supporting skills (optional): `unit-testing`, `flutter-mobile-qa`, `code-review`
+
+## Context notes
+
+- Provide the error message, stack trace, reproduction steps, and expected vs. actual behavior.
+- Debugger follows the 5-step protocol: capture, reproduce, isolate, fix, verify.
+
+## Workflow steps
+
+1. Explorer reads the bug report and maps the affected code paths.
+2. Debugger reproduces the issue, traces to root cause, and implements a minimal fix.
+3. Tester runs the previously failing test plus regression tests.
+4. Reviewer checks the fix is correct, minimal, and introduces no new issues.
+5. If the fix is insufficient, debugger iterates with new evidence.
+
+## Verification
+
+- Root cause identified and documented.
+- Fix is minimal and targeted (no unrelated changes).
+- Previously failing test passes and no regressions introduced.
+
+## Output Contract
+
+```yaml
+WORKFLOW_RESULT:
+  primary_agent: debugger
+  supporting_agents: [explorer, tester, reviewer]
+  root_cause: <string>
+  fix_summary: <string>
+  changed_artifacts: [<path>]
+  regression_checks: [<command or test>]
+  follow_up_items: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/codex/generated-skills/deploy/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: deploy
+description: "CI/CD and deployment setup: configure pipelines, Docker, infrastructure, test the pipeline, and review the configuration."
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "deploy"
+  platform: "Codex"
+  command: "/deploy"
+compatibility: Codex
+---
+# Deploy Workflow
+## When to use
+
+Use for CI/CD pipeline setup, Docker configuration, Kubernetes manifests, deployment automation, or infrastructure changes.
+
+## Agent Chain
+
+`planner` -> `implementer` -> `tester` -> `reviewer`
+
+## Routing
+
+1. **Plan**: `@planner` defines the deployment path, risks, rollback points, and validation gates.
+2. **Build**: `@implementer` creates or modifies pipeline configs, Dockerfiles, or infrastructure definitions.
+3. **Test**: `@tester` validates the pipeline (dry runs, container builds, integration checks).
+4. **Review**: `@reviewer` reviews the configuration for correctness and security.
+
+## Skill Routing
+
+- Primary skills: `ci-cd-pipeline`, `docker-compose-dev`
+- Supporting skills (optional): `kubernetes-deploy`, `integration-testing`, `code-review`, `owasp-security-review`
+
+## Context notes
+
+- Provide the deployment target, requirements, and any infrastructure constraints.
+- Implementer follows the project's existing infrastructure patterns.
+
+## Workflow steps
+
+1. Planner analyzes the current deployment setup and requirements.
+2. Implementer implements the pipeline or infrastructure changes.
+3. Tester runs pipeline checks, container builds, or dry-run deployments.
+4. Reviewer validates security (no hardcoded secrets, least-privilege, image scanning).
+5. If issues are found, implementer iterates on the configuration.
+
+## Verification
+
+- Pipeline runs successfully (build, test, deploy stages pass).
+- No hardcoded secrets in configuration files.
+- Rollback procedure documented and tested.
+
+## Output Contract
+
+```yaml
+WORKFLOW_RESULT:
+  primary_agent: implementer
+  supporting_agents: [planner, tester, reviewer]
+  pipeline_status: <pass|fail>
+  changed_artifacts: [<path>]
+  secrets_hardcoded: <number>
+  rollback_documented: <boolean>
+  follow_up_items: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/codex/generated-skills/design-audit/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: design-audit
+description: "Audit an existing interface against the design engine, token language, accessibility, and anti-generic UI constraints."
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "design-audit"
+  platform: "Codex"
+  command: "/design-audit"
+compatibility: Codex
+---
+# Design Audit Workflow
+## When to use
+
+Use when an interface exists and needs a design-system, UX, or anti-slop audit before more implementation.
+
+## Agent Chain
+
+`explorer` -> `reviewer`
+
+## Routing
+
+1. **Explore**: `@explorer` inspects the target screens, existing tokens, and any relevant design-state docs.
+2. **Review**: `@reviewer` evaluates visual direction, UX clarity, accessibility, and anti-generic design quality.
+3. **Return**: `@reviewer` reports findings with concrete references to the current UI and design state.
+
+## Skill Routing
+
+- Primary skills: `frontend-design`, `frontend-design-core`
+- Supporting skills (optional): `frontend-design-style-selector`, `frontend-design-mobile-patterns`, `code-review`
+
+## Context notes
+
+- Provide the target screen or app surface, the current quality concern, and whether the audit is visual, UX, or both.
+- This route should point back to canonical design state or call out where design state is missing.
+
+## Workflow steps
+
+1. Explorer inspects the current interface, token usage, and relevant design state.
+2. Reviewer evaluates visual direction, consistency, accessibility, and anti-generic design quality.
+3. Reviewer reports concrete findings and recommends the next design or implementation route.
+
+## Verification
+
+- Findings reference the current design state or the absence of one.
+- Distinctive design, consistency, accessibility, and component rhythm are all assessed.
+
+## Output Contract
+
+```yaml
+WORKFLOW_RESULT:
+  primary_agent: reviewer
+  supporting_agents: [explorer]
+  findings_count: <number>
+  referenced_design_artifacts: [<path>] | []
+  follow_up_items: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/codex/generated-skills/design-refresh/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: design-refresh
+description: "Refresh design state and implementation surfaces after product direction, design tokens, or major UI structure changes."
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "design-refresh"
+  platform: "Codex"
+  command: "/design-refresh"
+compatibility: Codex
+---
+# Design Refresh Workflow
+## When to use
+
+Use when the product direction changed and the design system, overlays, or Stitch mirror need a coordinated refresh.
+
+## Agent Chain
+
+`explorer` -> `planner` -> `implementer` -> `reviewer`
+
+## Routing
+
+1. **Explore**: `@explorer` finds the current design docs, overlays, and implementation surfaces touched by the direction change.
+2. **Plan**: `@planner` decides what must be refreshed and what can stay stable.
+3. **Implement**: `@implementer` updates canonical design state, overlays, and compatibility mirrors.
+4. **Review**: `@reviewer` checks that the refreshed design state is coherent and ready for downstream implementation.
+
+## Skill Routing
+
+- Primary skills: `frontend-design`, `frontend-design-core`, `frontend-design-system`
+- Supporting skills (optional): `frontend-design-style-selector`, `frontend-design-screen-brief`, `stitch-design-system`, `tech-doc`
+
+## Context notes
+
+- Provide what changed in product direction or UI structure and which downstream surfaces are now stale.
+- This route refreshes design state; it should not silently skip dependent overlays or the Stitch mirror.
+
+## Workflow steps
+
+1. Explorer finds the current design docs, overlays, and implementation surfaces touched by the direction change.
+2. Planner decides what must be refreshed and what can stay stable.
+3. Implementer updates canonical design state, overlays, and compatibility mirrors.
+4. Reviewer checks that the refreshed design state is coherent and ready for downstream implementation.
+
+## Verification
+
+- Canonical design state and overlays are updated together.
+- Downstream design consumers are told what changed.
+- Stitch compatibility artifacts are refreshed only from canonical state.
+
+## Output Contract
+
+```yaml
+WORKFLOW_RESULT:
+  primary_agent: implementer
+  supporting_agents: [explorer, planner, reviewer]
+  refreshed_artifacts: [<path>]
+  stitch_mirror_updated: <true|false>
+  follow_up_items: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/codex/generated-skills/design-screen/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: design-screen
+description: "Resolve the design engine first, produce a high-signal screen brief, then optionally hand off to Stitch or implementation."
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "design-screen"
+  platform: "Codex"
+  command: "/design-screen"
+compatibility: Codex
+---
+# Design Screen Workflow
+## When to use
+
+Use when the task is about shaping a concrete page or screen, especially before Stitch generation or Flutter/mobile implementation.
+
+## Agent Chain
+
+`explorer` -> `planner` -> `implementer`
+
+## Routing
+
+1. **Explore**: `@explorer` reads the current product context, UI patterns, and any existing design state.
+2. **Plan**: `@planner` chooses the applicable design overlays and decides whether Stitch is needed.
+3. **Implement**: `@implementer` resolves the design state, writes the screen brief, and only then performs Stitch or implementation handoff work.
+
+## Skill Routing
+
+- Primary skills: `frontend-design`, `frontend-design-core`, `frontend-design-style-selector`, `frontend-design-screen-brief`
+- Supporting skills (optional): `frontend-design-mobile-patterns`, `stitch-prompt-enhancement`, `stitch-design-system`, `stitch-design-orchestrator`, `frontend-design-implementation-handoff`, `stitch-implementation-handoff`
+
+## Stitch Gate
+
+Do not call Stitch until:
+
+1. `frontend-design` has run
+2. the canonical design state exists or is refreshed in the same run
+3. the screen brief is ready
+4. Stitch status/tool discovery succeeds
+
+## Context notes
+
+- Provide the product goal, target platform, and whether the screen is greenfield, a redesign, or a targeted edit.
+- This route can end in either a screen brief, a Stitch call, or direct implementation handoff depending on scope.
+
+## Workflow steps
+
+1. Explorer surveys the relevant product surface and existing design state.
+2. Planner resolves the applicable canonical design state and overlays.
+3. Implementer writes the screen brief and decides whether the next step is Stitch or direct implementation.
+4. If Stitch is used, the implementer follows the Stitch gate and hands the final artifact into implementation.
+
+## Verification
+
+- The brief is concrete enough for implementation or Stitch.
+- The route explains whether the next step is direct implementation or Stitch.
+- Stitch is never the first design step.
+
+## Output Contract
+
+```yaml
+WORKFLOW_RESULT:
+  primary_agent: implementer
+  supporting_agents: [explorer, planner]
+  screen_briefs: [<path-or-label>]
+  stitch_used: <true|false>
+  design_state_inputs: [<path>]
+  follow_up_items: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/codex/generated-skills/design-system/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: design-system
+description: "Establish or refresh canonical design state, token language, overlays, and Stitch compatibility before implementation."
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "design-system"
+  platform: "Codex"
+  command: "/design-system"
+compatibility: Codex
+---
+# Design System Workflow
+## When to use
+
+Use when the project needs a durable design foundation before screen generation or implementation.
+
+## Agent Chain
+
+`explorer` -> `planner` -> `implementer`
+
+## Routing
+
+1. **Explore**: `@explorer` reads current UI code, tokens, brand cues, and platform constraints.
+2. **Plan**: `@planner` chooses the design direction and the required design-state files.
+3. **Implement**: `@implementer` writes or refreshes `docs/foundation/DESIGN.md`, overlays, and the Stitch mirror when needed.
+
+## Skill Routing
+
+- Primary skills: `frontend-design`, `frontend-design-core`, `frontend-design-style-selector`, `frontend-design-system`
+- Supporting skills (optional): `frontend-design-mobile-patterns`, `stitch-design-system`, `tech-doc`
+
+## Context notes
+
+- Provide the target product surface, intended audience, and any existing brand or token constraints.
+- This route should refresh canonical design state before downstream screen generation or implementation.
+
+## Workflow steps
+
+1. Explorer surveys the current UI code, tokens, and existing design documents.
+2. Planner chooses the visual direction and identifies which canonical docs or overlays need refresh.
+3. Implementer writes or updates `docs/foundation/DESIGN.md`, overlays, and the Stitch mirror when needed.
+4. The route returns the refreshed design state and the next recommended design or implementation step.
+
+## Verification
+
+- `docs/foundation/DESIGN.md` exists and is coherent.
+- Overlays exist only when scoped detail is actually needed.
+- `.stitch/DESIGN.md` is synchronized when Stitch work is in scope.
+
+## Output Contract
+
+```yaml
+WORKFLOW_RESULT:
+  primary_agent: implementer
+  supporting_agents: [explorer, planner]
+  design_artifacts: [docs/foundation/DESIGN.md]
+  overlays_updated: [<path>] | []
+  stitch_mirror_updated: <true|false>
+  follow_up_items: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/codex/generated-skills/implement/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: implement
+description: "End-to-end feature implementation: explore, plan, implement, test, review, and optionally run the Stitch UI sequence for design-first screen generation."
+license: MIT
+metadata:
+  author: cubis-foundry
+  route-kind: "workflow"
+  route-id: "implement"
+  platform: "Codex"
+  command: "/implement"
+compatibility: Codex
+---
+# Implement Workflow
+## When to use
+
+Use for building new features, refactors, documentation refreshes, onboarding tasks, or post-design implementation work that needs the full lifecycle: planning, implementation, testing, and review.
+
+## Agent Chain
+
+`explorer` -> `planner` -> `implementer` -> `tester` -> `reviewer`
+
+## Routing
+
+1. **Explore**: `@explorer` maps the code area and existing patterns when the task is non-trivial.
+2. **Plan**: `@planner` reads the requirements and existing code, then produces an implementation plan.
+3. **Implement**: `@implementer` executes the plan, writing production-quality code.
+4. **Test**: `@tester` writes and runs tests verifying the implementation.
+5. **Review**: `@reviewer` performs quality and security review, then approves or requests changes.
+
+## Skill Routing
+
+- Primary skills: `api-design`, `typescript-best-practices`
+- Supporting skills (optional): `spec-driven-delivery`, `system-design`, `unit-testing`, `integration-testing`, `playwright-interactive`, `code-review`, `owasp-security-review`, `frontend-design`, `stitch-prompt-enhancement`, `stitch-design-orchestrator`, `stitch-design-system`, `stitch-implementation-handoff`
+
+## Context notes
+
+- Provide the feature requirements, acceptance criteria, and any design constraints.
+- Implementer follows existing codebase patterns and conventions.
+- Use this workflow for doc-only or refactor-heavy work when you want one coordinated pass instead of separate routes.
+- If the task is primarily about shaping a screen, design system, or Stitch prompt, prefer `/design-screen` or `/design-system` first and return here only for implementation/handoff.
+
+## Stitch UI mode
+
+Use `/implement` only after `/design-screen` or `/design-system` resolved the design state and the work now needs implementation or implementation handoff.
+
+1. Load `frontend-design` first, starting with `visual-direction` and `design-tokens`.
+2. Load `stitch-prompt-enhancement` before any Stitch tool call.
+3. If `docs/foundation/DESIGN.md` is missing, stale, or the work spans multiple screens, run `stitch-design-system` and mirror the result to `.stitch/DESIGN.md`.
+4. Verify `stitch_get_status`, `mcp_gateway_status`, and `stitch_list_enabled_tools`.
+5. Reuse an existing Stitch project when the work belongs to the same app or feature line. Call `list_projects` before `create_project`, and call `list_screens` before deciding whether the next step is a fresh generation or an edit.
+6. Choose the smallest Stitch tool path: `generate_screen_from_text`, `edit_screens`, `generate_variants`, or design-system tools only when the design system itself is the task.
+7. Default to `GEMINI_3_1_PRO` for complex or multi-screen UI work. Use `GEMINI_3_FLASH` only for speed-first drafts or narrow edits.
+8. Surface Stitch suggestions before retrying. Allow at most two automatic retries with backoff.
+9. If a Stitch generation call times out, check `list_screens` before treating it as failed.
+10. Fetch the final artifact with `get_screen`, then run `stitch-implementation-handoff` before normal implementation, test, and review.
+
+## Workflow steps
+
+1. Explorer maps the relevant code and patterns when the request is not trivial.
+2. Planner analyzes requirements and produces a structured implementation plan.
+3. Implementer executes the plan step by step, verifying compilation after each change.
+4. Tester writes tests for the new code and runs the relevant test suite.
+5. Reviewer evaluates code quality, patterns, correctness, and security.
+6. If changes are requested, implementer applies fixes and the cycle repeats from step 4.
+
+## Verification
+
+- All planned changes implemented and code compiles without errors.
+- Tests pass and cover the new functionality.
+- Code review approved with no critical findings.
+- For Stitch UI mode, design context is resolved before generation and the final implementation reuses repo-native components and tokens.
+
+## Output Contract
+
+```yaml
+WORKFLOW_RESULT:
+  primary_agent: implementer
+  supporting_agents: [explorer, planner, tester, reviewer]
+  changed_artifacts: [<path>]
+  tests_status: <pass|fail>
+  review_status: <approve|request_changes>
+  follow_up_items: [<string>] | []
+```