oma-dev-workflow

# Dev Workflow - Monorepo Task Automation Specialist

## Scheduling

### Goal
Set up, run, optimize, and troubleshoot reproducible development workflows in monorepos using `mise`, task automation, validation pipelines, CI/CD, migrations, i18n builds, and release coordination.

### Intent signature
- User asks about dev servers, mise tasks, lint/format/typecheck/test/build, git hooks, CI/CD, migrations, generated clients, i18n builds, or release automation.
- User needs workflow execution or developer environment setup rather than product feature implementation.

### When to use

- Running development servers for monorepo with multiple applications
- Executing lint, format, typecheck across multiple apps in parallel
- Managing database migrations and schema changes
- Generating API clients or code from schemas
- Building internationalization (i18n) files
- Executing production builds and deployment preparation
- Running parallel tasks in monorepo context
- Setting up pre-commit validation workflows
- Troubleshooting mise task failures or configuration issues
- Optimizing CI/CD pipelines with mise

### When NOT to use

- Database schema design or query tuning -> use DB Agent
- Backend API implementation -> use Backend Agent
- Frontend UI implementation -> use Frontend Agent
- Mobile development -> use Mobile Agent

### Expected inputs
- Requested workflow operation, affected apps/packages, and current monorepo structure
- `mise.toml`, task definitions, CI files, migration/i18n/build configs, and failure logs when relevant
- Desired validation, setup, or release outcome

### Expected outputs
- Executed or documented mise task workflow
- Updated workflow config, CI/CD pipeline, hooks, env template, or release guidance when requested
- Status report with commands, outputs, failures, and next actions

### Dependencies
- `mise`, project task definitions, runtime versions, package managers behind mise tasks
- Resource guides for validation, database patterns, API workflows, i18n, release coordination, and troubleshooting

### Control-flow features
- Branches by affected apps, task dependency graph, port availability, task failure, and CI/release context
- Calls local process commands; may write workflow/config files
- Must avoid destructive tasks and secrets in workflow configs

## Structural Flow

### Entry
1. Identify affected apps/packages and requested workflow outcome.
2. Read `mise.toml` files and available tasks.
3. Determine whether tasks can run in parallel or must be sequential.

### Scenes
1. **PREPARE**: Analyze requirements, task graph, runtime prerequisites, and ports.
2. **ACQUIRE**: Inspect mise config, task definitions, CI hooks, env patterns, and logs.
3. **ACT**: Run or modify mise tasks, workflow configs, or validation pipelines.
4. **VERIFY**: Check exit codes, generated artifacts, logs, and CI compatibility.
5. **FINALIZE**: Report command status, duration, failures, and next steps.

### Transitions
- If runtime versions changed, run `mise install`.
- If changed-file tasks exist, prefer changed-scope validation.
- If port is occupied, resolve or select another port before starting dev server.
- If a task is unfamiliar, read its definition before running.

### Failure and recovery
- If task is missing, run `mise tasks --all`.
- If runtime is missing, run or recommend `mise install`.
- If task hangs, check for prompts or long-running dev-server behavior.
- If destructive task is requested, require confirmation.

### Exit
- Success: workflow runs or config changes are verified.
- Partial success: task failures, missing runtime, or CI/environment blockers are explicit.

## Logical Operations

### Actions
| Action | SSL primitive | Evidence |
|--------|---------------|----------|
| Read task definitions | `READ` | `mise.toml`, CI config |
| Select task strategy | `SELECT` | Parallel/sequential/changed-scope |
| Run workflow commands | `CALL_TOOL` | `mise run`, `mise install`, `mise tasks` |
| Write workflow config | `WRITE` | Hooks, CI, env templates |
| Validate outputs | `VALIDATE` | Exit codes, logs, artifacts |
| Report status | `NOTIFY` | Final workflow summary |

### Tools and instruments
- `mise`, shell, CI/CD tooling, project package manager tasks behind mise
- Resource guides for validation, database, API, i18n, release, and troubleshooting

### Canonical command path
```bash
mise tasks --all
mise install
mise run lint
mise run test
```

For app-specific tasks:
```bash
mise run //{path}:{task}
```

### Resource scope
| Scope | Resource target |
|-------|-----------------|
| `CODEBASE` | `mise.toml`, CI configs, scripts, generated clients |
| `LOCAL_FS` | Env templates, build outputs, logs |
| `PROCESS` | mise, build, test, lint, dev-server commands |
| `CREDENTIALS` | Secrets must not be hardcoded in workflow configs |

### Preconditions
- Target workflow and affected project area are identifiable.
- Task definitions can be discovered or missing-task state is reported.

### Effects and side effects
- May start dev servers, run tests/builds, generate clients, run migrations, or edit workflow configs.
- May consume CPU/time or occupy ports.

### Guardrails

1. Always use `mise run` tasks instead of direct package manager commands
2. Run `mise install` after pulling changes that might update runtime versions
3. Use parallel tasks (`mise run lint`, `mise run test`) for independent operations
4. Run lint/test only on apps with changed files (`lint:changed`, `test:changed`)
5. Validate commit messages with commitlint before committing
6. Run pre-commit validation pipeline for staged files only
7. Configure CI to skip unchanged apps for faster builds
8. Check `mise tasks --all` to discover available tasks before running
9. Verify task output and exit codes for CI/CD integration
10. Document task dependencies in mise.toml comments
11. Use consistent task naming conventions across apps
12. Enable mise in CI/CD pipelines for reproducible builds
13. Pin runtime versions in mise.t