owflow 0.5.0 → 0.6.0

package/README.md

@@ -130,15 +130,26 @@ You can always be explicit when you prefer - arguments and flags simply override
 
 ## Supported Workflows
 
-| Command                | Use When                                    |
-| ---------------------- | ------------------------------------------- |
-| `/owflow:development`  | Features, bug fixes, enhancements           |
-| `/owflow:research`     | Research with synthesis and solution design |
-| `/owflow:performance`  | Optimizing speed or resource usage          |
-| `/owflow:migration`    | Changing technologies or patterns           |
+| Command                    | Use When                                       |
+| -------------------------- | ---------------------------------------------- |
+| `/owflow:development`      | Features, bug fixes, enhancements              |
+| `/owflow:research`         | Research with synthesis and solution design    |
+| `/owflow:performance`      | Optimizing speed or resource usage             |
+| `/owflow:migration`        | Changing technologies or patterns              |
 
 Use `/owflow:work` as a single entry point — it classifies the task with the `task-classifier` subagent and routes to the right workflow.
 
+### Autonomous Workflows
+
+Each workflow has a `/owflow:goal-*` equivalent that runs the same pipeline back-to-back in one session, pausing at decision gates between steps. Both modes share one task state, so you can mix them freely on a single task.
+
+| Command                    | Runs                          |
+| -------------------------- | ----------------------------- |
+| `/owflow:goal-development` | The full development pipeline |
+| `/owflow:goal-research`    | The full research pipeline    |
+| `/owflow:goal-performance` | The full performance pipeline |
+| `/owflow:goal-migration`   | The full migration pipeline   |
+
 ### Research Utility
 
 | Command                       | Use When                                                                        |
@@ -195,6 +206,17 @@ The full `/owflow:development` workflow consists of standalone subskills — `/o
 
 If a subskill is invoked too early in the workflow (prerequisite phases not yet complete), it stops and tells you exactly which steps to run first, in order. If the workflow state doesn't exist yet, use `/owflow:development <description>` to start from scratch.
 
+### Fine-Grained Control: Performance Subskills
+
+The full `/owflow:performance` workflow consists of standalone subskills — `/owflow:performance-analyze`, `/owflow:performance-spec`, `/owflow:performance-plan`, `/owflow:performance-implement`, `/owflow:performance-verify`, `/owflow:performance-finalize` — which you can also invoke individually. Each accepts a task path, or just a task-directory identifier:
+
+```bash
+/owflow:performance-analyze 2026-01-12-dashboard-queries
+/owflow:performance-verify .owflow/tasks/performance/2026-01-12-dashboard-queries
+```
+
+If a subskill is invoked too early in the workflow (prerequisite steps not yet complete), it stops and tells you exactly which steps to run first, in order. If the workflow state doesn't exist yet, use `/owflow:performance <description>` to start from scratch.
+
 ## Standards-Aware Development
 
 This is the key differentiator. Owflow doesn't just run workflows - it learns your project's conventions and enforces them:

package/dist/agents/bottleneck-analyzer.md

@@ -74,9 +74,11 @@ Detect ORM calls inside iteration constructs:
   - **Django**: Attribute access on queryset (lazy loading) inside template/view loops
   - **Rails**: Association method calls without `.includes()` or `.preload()`
   - **SQLAlchemy**: Relationship access without `joinedload()` or `subqueryload()`
+  - **Hibernate**: `@ManyToOne` lazy access in loop → `@Fetch(FetchMode.JOIN)` or JPQL `JOIN FETCH`
 
 **Missing Index Detection** (read schema/migrations, don't run EXPLAIN):
 - Read migration files and schema definitions to catalog existing indexes
+- Per-framework index locations: Rails `add_index`, Django `db_index` / Meta `indexes`, Sequelize `indexes`, Prisma `@@index`/`@@unique`, TypeORM `@Index`, SQL migrations `CREATE INDEX`
 - Grep for query patterns (WHERE, ORDER BY, JOIN columns)
 - Cross-reference: columns filtered/sorted on without corresponding indexes
 - Flag composite conditions without composite indexes
@@ -85,7 +87,9 @@ Detect ORM calls inside iteration constructs:
 - `SELECT *` when only a few columns are needed
 - Missing `LIMIT` on queries against large tables
 - String operations in WHERE clauses (`LIKE '%...'`)
+- `OR` conditions on different columns (prevents single index use)
 - Subqueries that could be JOINs
+- `DISTINCT` masking a JOIN issue
 - Unbounded queries without pagination
 
 **Output**: List of database bottlenecks with file:line references and fix approach

package/dist/agents/production-readiness-checker.md

@@ -268,7 +268,7 @@ issue_counts:
 
 ## Integration
 
-**Invoked by**: implementation-verifier (Phase 3), performance orchestrator (Phase 4), standalone via `/owflow:reviews-production-readiness` command
+**Invoked by**: implementation-verifier (Phase 3; inside `performance-verify` for performance tasks), standalone via `/owflow:reviews-production-readiness` command
 
 **Prerequisites**:
 

package/dist/commands/work.md

@@ -146,7 +146,7 @@ Use Skill tool:
 Examples:
 
 - Resume development: `skill: "owflow:development"` with `args: "--resume .owflow/tasks/development/2025-10-23-fix"`
-- Restart from step: `skill: "owflow:development"` with `args: "--resume .owflow/tasks/development/2025-10-26-auth --from=verification-done"` (development, research, and migration tasks use descriptive step slugs in `completed_phases`; performance is the remaining `phase-N` holdout)
+- Restart from step: `skill: "owflow:development"` with `args: "--resume .owflow/tasks/development/2025-10-26-auth --from=verification-done"` (development, research, performance, and migration tasks use descriptive step slugs in `completed_phases`)
 - Fresh attempts: `skill: "owflow:development"` with `args: "--resume .owflow/tasks/development/2025-10-23-fix --reset-attempts"`
 
 ### Step 3: Classify & Route New Task
@@ -236,7 +236,7 @@ Display:
 | Workflow Type | Skill         | Args                                                |
 | ------------- | ------------- | --------------------------------------------------- |
 | development   | `development` | `--resume [path] [--from=<slug>] [--reset-attempts]` |
-| performance   | `performance` | `--resume [path] [--from=PHASE]`                    |
+| performance   | `performance` | `--resume [path] [--from=<slug>]`                   |
 | migration     | `migration`   | `--resume [path] [--from=<slug>]`                   |
 | research      | `research`    | `--resume [path] [--from=<slug>]`                   |
 

package/dist/skills/codebase-analyzer/SKILL.md

@@ -159,4 +159,4 @@ risk_level: low|low-medium|medium|medium-high|high
 |-------------|-------|---------------|
 | development orchestrator | `codebase-analysed` | `codebase-analysis.md` (default) |
 | migration-analyze | `state-analysed` | `current-state-analysis.md` |
-| performance orchestrator | `phase-1` | `codebase-analysis.md` (default) |
+| performance-analyze | `codebase-analysed` | `codebase-analysis.md` (default) |

package/dist/skills/diagrams-mermaid/references/reference.md

@@ -140,7 +140,7 @@ Integrated into:
 - `src/skills/flow-init/SKILL.md` - Phase 6 (architecture and tech-stack doc refinement)
 - `src/skills/dev-spec/SKILL.md` - `spec-written` (spec refinement); `src/skills/dev-plan/SKILL.md` - `plan-created` (plan refinement)
 - `src/skills/research-design/SKILL.md` - `design-generated` (high-level design refinement)
-- `src/skills/performance/SKILL.md` - `phase-3` (spec refinement), `phase-5` (plan refinement)
+- `src/skills/performance-spec/SKILL.md` - `spec-written` (spec refinement); `src/skills/performance-plan/SKILL.md` - `plan-created` (plan refinement)
 - `src/skills/migration-spec/SKILL.md` - `strategy-specified` (spec refinement); `src/skills/migration-plan/SKILL.md` - `plan-created` (plan refinement)
 
 Reference files:

package/dist/skills/goal-performance/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: owflow:goal-performance
+description: Full orchestrated performance wrapper — runs ALL performance steps in one session by invoking every performance-* subskill in sequence with question gates between them. Use /owflow:performance for the same lifecycle in assisted mode — tasks can mix both modes freely.
+argument-hint: "[task description | task-path] [--from=<step-slug>]"
+user-invocable: true
+---
+
+# Orchestrated Performance Wrapper
+
+Autonomous mode for performance tasks. Initializes (or resumes) the task, then invokes every required `performance-*` subskill back-to-back via the Skill tool, pausing at gates between subskills. Shares `orchestrator-state.yml` with assisted mode (`/owflow:performance`) — tasks can mix both modes freely.
+
+Gates follow the shared contract in [Gate Contract](../orchestrator-framework/references/gate-contract.md) — orchestrated mode exception: each subskill's own Exit Gate acceptance question IS the loop gate (Accept = continue to the next subskill). **At intermediate hops the wrapper MUST NOT add a second consecutive `question`**; after the final hop, the wrapper Exit Gate below fires exactly one workflow-closure confirmation.
+
+## Input / Output Artifacts
+
+| Artifact | This wrapper | Assisted mode (`/owflow:performance`) |
+| --- | --- | --- |
+| Consumed: argument (description / path) | performance issue description (new task) or task path/identifier (resume) | same |
+| Consumed/produced: all task artifacts | owned entirely by the invoked subskills (none here — delegate, never inline) | same |
+| State write | init as the dispatcher; during the loop ONLY `orchestrator.task_ids` + `orchestrator.updated` | init + drop-only resume trim |
+
+## Entry Gate
+
+Identical to the performance dispatcher — complete ALL of its entry-gate steps first (see `../performance/SKILL.md` Entry Gate):
+
+1. Read the framework reference files NOW, exactly as the performance dispatcher's Step 1: the [Dispatcher & Handoff Pattern](../orchestrator-framework/references/dispatcher-handoff.md), the [Delegation Rules](../orchestrator-framework/references/delegation-rules.md), and the [Orchestrator Patterns](../orchestrator-framework/references/orchestrator-patterns.md).
+2. Resolve the argument the same way the performance dispatcher does: task path or identifier (a directory, or a directory name under `.owflow/tasks/performance/`) → **resume mode** (read `orchestrator-state.yml`, run the dispatcher's drop-only resume validation, derive the next step from the dispatcher's routing table, with `--from=<step-slug>` overriding); a performance issue description (free text) → new task; nothing provided → ask via `question` — "What is slow or performance-constrained? Describe the symptom (endpoint, page, job), expected vs actual behavior, and any profiling data you have." — then WAIT. Missing state file → print `No performance task found at <path>. Run /owflow:performance <description> to start a task from scratch.` and STOP.
+3. Initialize (new task) exactly as the dispatcher: create `.owflow/tasks/performance/YYYY-MM-DD-task-name/` with `analysis/`, `analysis/user-profiling-data/`, `implementation/`, `verification/`, then `orchestrator-state.yml` from the performance template — `task.title` / `task.description` from the description, `task.status: in_progress`, `orchestrator.task_path`, `orchestrator.entry_point: "performance"`, and project docs into `performance_context.project_doc_paths`. **CRITICAL**: use the `verify_template` tool immediately after creation to check YAML validity against `orchestrator-state-performance.yml`.
+4. Create the six task items via `TaskCreate` exactly as the dispatcher does (one per subskill), set `addBlockedBy` chains, and record their ids in `orchestrator.task_ids`. On resume, refresh the already-evidenced items instead of re-creating them. Update item statuses as the loop progresses.
+
+**Output**:
+
+```
+🚀 Orchestrated Performance
+
+Task: [performance issue description]
+Directory: [task-path]
+Loop: performance-analyze → performance-spec → performance-plan → performance-implement → performance-verify → performance-finalize
+```
+
+---
+
+## The Loop
+
+For each subskill in the Sequence table below, execute — skipping any row whose **Runs when** condition is not met. The condition is authoritative: a multi-slug row (row 2) still runs when one of its slugs is complete but the other is pending (the audit re-entry case).
+
+1. **Announce**: 1-line step banner.
+2. **Invoke**: Skill tool with `name: "<subskill>"` and `prompt: "<task-path> [flags relevant to that subskill]"`. The subskill owns its Entry Gate, delegation, and state updates. Never run a subskill's or an agent's work inline.
+3. **Verify handback**: after the skill returns, re-read `orchestrator-state.yml` — confirm the row's expected slug(s) are present in `completed_phases`. A re-entered row may add only its pending slug, and an audit skip records `options.spec_audit_enabled: false` with no new slug — those are legitimate completions, not early stops. A subskill that stopped at its entry check (missing prerequisites, no task) ENDS the loop and its routing/blocked message is relayed to the user.
+4. **Gate (the subskill's Exit Gate IS the loop gate)**: each subskill presents its results box and fires its own results-acceptance `question` before its handoff hint (orchestrated-mode exception, [Gate Contract](../orchestrator-framework/references/gate-contract.md)). When the user answers **Accept**, treat it as "continue to the next subskill" and invoke it. Any other answer (Adjust / Discuss / Stop here) ends the loop exactly like a rejected gate. There is exactly ONE gate per hop — **the wrapper adds NO second consecutive `question` at intermediate hops**; the terminal wrapper Exit Gate (below) is the single workflow-closure confirmation after the final hop.
+
+### Sequence
+
+| Order | Subskill | Runs when (from state) | Slugs verified after |
+| --- | --- | --- | --- |
+| 1 | `performance-analyze` | new task, OR `codebase-analysed` absent, OR (`codebase-analysed` present AND `bottlenecks-identified` absent) | `codebase-analysed`, `bottlenecks-identified` |
+| 2 | `performance-spec` | `bottlenecks-identified` complete AND [ (`spec-written` absent) OR (`spec-audited` absent AND (`options.spec_audit_enabled` is null OR `true`)) ] | `spec-written` (+ `spec-audited` when the audit ran) |
+| 3 | `performance-plan` | `spec-written` complete AND `options.spec_audit_enabled` non-null — settled, NEVER `spec-audited` — AND `plan-created` absent | `plan-created` |
+| 4 | `performance-implement` | `plan-created` complete AND `implementation-done` absent | `implementation-done` |
+| 5 | `performance-verify` | `implementation-done` complete AND [ `options-chosen` absent OR `verification-done` absent ] | `options-chosen`, `verification-done` |
+| 6 | `performance-finalize` | `verification-done` complete AND `task-completed` absent | `task-completed` + `task.status: completed` |
+
+Six rows, ZERO user-choice rows: every performance conditional is an in-skill `question` owned by a subskill, never a chain decision this wrapper makes.
+
+### Decisions the wrapper never answers
+
+The six in-skill decision questions below belong to the subskill that owns them — they are NEVER auto-accepted, pre-answered, or skipped by this wrapper (decisions are never silently accepted):
+
+| Subskill | In-skill decision questions |
+| --- | --- |
+| `performance-analyze` | performance concerns / hotspots / goals (max 5); profiling-data offer |
+| `performance-spec` | bottleneck priorities / constraints / targets; run the specification audit? |
+| `performance-verify` | which additional verification checks; fix-set selection + re-run verification |
+
+`performance-plan`, `performance-implement`, and `performance-finalize` have no in-skill decision questions — their only gates are their Exit Gates (the loop gate above).
+
+**Interruptible**: at any gate the user may answer "stop" — print the standard handoff block (`/owflow:performance <task-path>` resume hint + the next command) and end the session. The task resumes later in either mode.
+
+`task-completed` already in `completed_phases` (with `task.status: completed`) → the task is TERMINAL: skip the Loop and present the wrapper Exit Gate.
+
+---
+
+## Exit Gate
+
+When `performance-finalize`'s own Exit Gate is accepted (`task-completed` recorded, `task.status: completed`):
+
+1. Mark the final task item completed via `TaskUpdate`.
+2. Present the wrapper terminal results box:
+
+```markdown
+## ✅ PERFORMANCE WORKFLOW COMPLETE — <task name>
+
+**Steps** — [executed step slugs, e.g. codebase-analysed → bottlenecks-identified → … → task-completed]
+**Bottlenecks found** — [P0/P1/P2/P3 counts]
+**Optimizations applied** — [count + key ones]
+**Verification** — [final verdict]
+**Estimated improvement** — [range from the analysis]
+
+**Artifacts**
+
+- `analysis/performance-analysis.md`
+- `implementation/work-log.md`
+- `verification/implementation-verification.md`
+```
+
+3. Use `question` — "Are these results correct?" with options: **Accept** (print the follow-up suggestions: measure the improvement, consider runtime profiling, `/owflow:standards-update "<lesson>"`, then end) / **Adjust** (re-open the affected `/owflow:performance-*` skill with the corrections) / **Discuss** (walk through the optimization summary, evidence, and measurement caveats) / **Stop here** (print the resume command `/owflow:performance <task-path>` and end).
+
+Then end. No further owflow commands are required.
+
+---
+
+## Loop Rules
+
+- **Delegate, never inline**: the wrapper only sequences — all step work happens inside subskills. If you catch yourself analyzing or implementing outside a subskill, STOP and invoke the subskill instead.
+- **State is the truth**: gates and routing read `orchestrator-state.yml`, not memory. Re-read after every subskill returns.
+- **Same state schema as assisted mode**: `completed_phases` step slugs (`codebase-analysed` … `task-completed`) are identical; resume works across modes.
+- **Wrapper writes almost nothing**: step slugs, summaries, and artifacts belong to the subskills — during the loop this wrapper writes ONLY `orchestrator.task_ids` (task items) and `orchestrator.updated` (timestamps).
+
+## Command Integration
+
+Invoked via:
+
+- `/owflow:goal-performance [description]` (new)
+- `/owflow:goal-performance [task-path] [--from=<step-slug>]` (resume)
+
+Alternative: `/owflow:performance` — same task in assisted mode (one subskill per invocation, fresh context each step).

package/dist/skills/orchestrator-framework/references/dispatcher-handoff.md

@@ -18,7 +18,7 @@ Orchestrators MAY delegate phase bodies to user-invocable **subskills** instead
    | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------- | ---------------------------------------------- |
    | development  | `codebase-analysed`, `gap-analysed`, `tdd-red-proven`, `spec-written`, `spec-audited`, `plan-created`, `implementation-done`, `tdd-green-proven`, `options-chosen`, `verification-done`, `e2e-run`, `docs-generated`, `task-completed` | `skills/development/SKILL.md`  | `templates/orchestrator-state-development.yml` |
    | research     | `brief-written`, `plan-created`, `findings-gathered`, `synthesis-complete`, `alternatives-generated`, `approaches-chosen`, `design-generated`, `research-completed`        | `skills/research/SKILL.md`       | `templates/orchestrator-state-research.yml`    |
-   | performance  | `phase-N` (legacy holdout — kept internally consistent)                                                                                                                     | `skills/performance/SKILL.md`    | `templates/orchestrator-state-performance.yml` |
+   | performance  | `codebase-analysed`, `bottlenecks-identified`, `spec-written`, `spec-audited`, `plan-created`, `implementation-done`, `options-chosen`, `verification-done`, `task-completed`                                                                                                                     | `skills/performance/SKILL.md`    | `templates/orchestrator-state-performance.yml` |
    | migration    | `state-analysed`, `target-planned`, `strategy-specified`, `plan-created`, `migration-executed`, `options-chosen`, `verification-done`, `issues-resolved`, `docs-generated`, `task-completed` | `skills/migration/SKILL.md`      | `templates/orchestrator-state-migration.yml`   |
 2. **Subskills are self-contained.** Each has: an entry check (validate state + prerequisite artifacts), an execute section (delegation via Skill/Task tools per the [Delegation Rules](delegation-rules.md)), and an exit (state update + closing ritual). **State updates are per-step**: a subskill writes `orchestrator-state.yml` immediately after each of its steps completes — appending only the step slug actually performed, bumping `orchestrator.updated`, recording failures in `failed_phases`/`auto_fix_attempts`, and validating with `verify_template` — never as a single end-of-skill write.
 3. **Closing ritual (handoff) → Exit Gate.** Every subskill ends with the **Exit Gate** contract, see [Gate Contract](gate-contract.md) (results box → results-acceptance question → next-step hint on accept → STOP).

package/dist/skills/orchestrator-framework/references/gate-contract.md

@@ -55,6 +55,11 @@ When a subskill is invoked with a task path/identifier whose `orchestrator-state
 - Task directory under `.owflow/tasks/migrations/`; template `orchestrator-state-migration.yml`; fresh-start hint: `Run /owflow:migration <description> to start a migration task from scratch.`
 - Skill starting points (used for the bootstrap question and `started_phase`): migration-analyze → `state-analysed`; migration-target → `target-planned`; migration-spec → `strategy-specified`; migration-plan → `plan-created`; migration-implement → `migration-executed`; migration-verify → `options-chosen`; migration-fix → `issues-resolved`; migration-finalize → `task-completed`.
 
+#### performance-* bootstrap
+
+- Task directory under `.owflow/tasks/performance/`; template `orchestrator-state-performance.yml`; fresh-start hint: `Run /owflow:performance <description> to start a task from scratch.`
+- Skill starting points (used for the bootstrap question and `started_phase`): performance-analyze → `codebase-analysed`; performance-spec → `spec-written`; performance-plan → `plan-created`; performance-implement → `implementation-done`; performance-verify → `options-chosen`; performance-finalize → `task-completed`.
+
 ### Deterministic entry checks (future)
 
 Entry-gate checks above are currently executed by the agent reading state. For more deterministic routing, future work considers (a) a small script that checks whether `orchestrator-state.yml` exists, parses it, and answers slug/next-step queries, and (b) an OpenCode lifecycle hook that automates these entry-gate checks for dev-* skills before they run. Until then, follow the rules above exactly as written.
@@ -112,6 +117,6 @@ The Exit Gate runs after all phase work and state updates are final. It presents
 
 ## Exceptions
 
-- **Dispatchers** (`development`, `research`, `migration`): the Exit Gate's acceptance question is adapted — the results box is the handoff block, and the question asks how to proceed (hand off to the suggested subskill / switch to autonomous mode / adjust / stop).
+- **Dispatchers** (`development`, `research`, `performance`, `migration`): the Exit Gate's acceptance question is adapted — the results box is the handoff block, and the question asks how to proceed (hand off to the suggested subskill / switch to autonomous mode / adjust / stop).
 - **Utility skills with explicit no-follow-up contracts** (`agents-md-generator`, `rule-reviewer`): the acceptance question is confirm-or-revise only; follow-up suggestions stay prohibited unless the user asks. See [confirm-or-revise exception](confirm-or-revise-exception.md).
-- **Orchestrated mode** (`goal-development`, `goal-research`, `goal-migration`): the subskill's own Exit Gate acceptance question IS the loop gate — Accept means "continue to the next subskill". The wrapper MUST NOT add a second consecutive `question`.
+- **Orchestrated mode** (`goal-development`, `goal-research`, `goal-performance`, `goal-migration`): the subskill's own Exit Gate acceptance question IS the loop gate — Accept means "continue to the next subskill". The wrapper MUST NOT add a second consecutive `question`.

package/dist/skills/orchestrator-framework/references/orchestrator-patterns.md

@@ -129,11 +129,11 @@ Orchestrators add domain-specific fields using `[domain]_context`:
 | Domain      | Context Field         | Example Fields                                     |
 | ----------- | --------------------- | -------------------------------------------------- |
 | Development | `task_context`        | risk_level, ui_heavy, architecture_decision        |
-| Performance | `performance_context` | baseline_p95, target_p95, optimizations_completed  |
+| Performance | `performance_context` | bottlenecks_identified, user_data_available, bottleneck_priorities, task_characteristics, phase_summaries |
 | Migration   | `migration_context`   | migration_type, target_system, risk_level          |
 | Research    | `research_context`    | research_type, research_question, confidence_level |
 
-See each orchestrator's SKILL.md "Domain Context" section for full schema.
+See each workflow's state template under `src/templates/` for the full extension schema.
 
 ### Shared: research_reference