owflow 0.4.3 → 0.6.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +32 -6
- package/dist/agents/bottleneck-analyzer.md +4 -0
- package/dist/agents/implementation-planner.md +1 -1
- package/dist/agents/production-readiness-checker.md +1 -1
- package/dist/agents/specification-creator.md +1 -1
- package/dist/commands/work.md +4 -4
- package/dist/skills/codebase-analyzer/SKILL.md +4 -4
- package/dist/skills/dev-verify/SKILL.md +3 -10
- package/dist/skills/diagrams-mermaid/references/reference.md +4 -4
- package/dist/skills/goal-migration/SKILL.md +114 -0
- package/dist/skills/goal-performance/SKILL.md +126 -0
- package/dist/skills/migration/SKILL.md +157 -296
- package/dist/skills/migration-analyze/SKILL.md +126 -0
- package/dist/skills/migration-finalize/SKILL.md +161 -0
- package/dist/skills/migration-fix/SKILL.md +155 -0
- package/dist/skills/migration-implement/SKILL.md +131 -0
- package/dist/skills/migration-plan/SKILL.md +131 -0
- package/dist/skills/migration-spec/SKILL.md +135 -0
- package/dist/skills/{migration → migration-spec}/references/migration-strategies.md +9 -9
- package/dist/skills/migration-target/SKILL.md +134 -0
- package/dist/skills/{migration → migration-target}/references/migration-types.md +22 -23
- package/dist/skills/migration-verify/SKILL.md +184 -0
- package/dist/skills/orchestrator-framework/references/dispatcher-handoff.md +2 -2
- package/dist/skills/orchestrator-framework/references/fix-loop-contract.md +65 -0
- package/dist/skills/orchestrator-framework/references/gate-contract.md +12 -2
- package/dist/skills/orchestrator-framework/references/orchestrator-patterns.md +6 -3
- package/dist/skills/performance/SKILL.md +162 -332
- package/dist/skills/performance-analyze/SKILL.md +129 -0
- package/dist/skills/{performance → performance-analyze}/references/performance-optimization-guide.md +1 -95
- package/dist/skills/performance-finalize/SKILL.md +117 -0
- package/dist/skills/performance-implement/SKILL.md +114 -0
- package/dist/skills/performance-plan/SKILL.md +112 -0
- package/dist/skills/performance-spec/SKILL.md +145 -0
- package/dist/skills/performance-verify/SKILL.md +164 -0
- package/dist/templates/orchestrator-state-migration.yml +49 -9
- package/dist/templates/orchestrator-state-performance.yml +20 -9
- package/package.json +1 -1
|
@@ -0,0 +1,145 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: owflow:performance-spec
|
|
3
|
+
description: Performance — requirements gathering, specification creation via delegation, diagram refinement, and conditional specification audit. Continues with performance-plan.
|
|
4
|
+
argument-hint: "[task-path-or-identifier]"
|
|
5
|
+
user-invocable: true
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Performance Spec — Requirements, Specification & Conditional Audit (spec-written, spec-audited)
|
|
9
|
+
|
|
10
|
+
Work step of the performance workflow. Presents the bottleneck analysis, gathers optimization priorities, constraints, and targets, creates the specification via delegation, refines it with diagrams, then offers an independent specification audit. State lives in `orchestrator-state.yml` — this skill reads it on entry and writes results on exit.
|
|
11
|
+
|
|
12
|
+
## Entry Gate
|
|
13
|
+
|
|
14
|
+
Resolve the argument BEFORE anything else (see [Gate Contract](../orchestrator-framework/references/gate-contract.md)). The argument may be:
|
|
15
|
+
|
|
16
|
+
- **Path** (absolute or project-relative) to the task directory — use as-is.
|
|
17
|
+
- **Identifier** — exact directory name inside `.owflow/tasks/performance/` (e.g., `2026-10-02-api-latency`); resolve to its path.
|
|
18
|
+
- **Description** — anything else (free text) is treated as a new performance task description: ask via `question` whether to start a fresh standard task at this step (mid-pipeline bootstrap) or route through `/owflow:performance <description>`; on decline, print the blocked block and STOP.
|
|
19
|
+
- If the argument is **missing**, the path does **not exist**, or matches **no identifier** → print the blocked block, then STOP (never guess or auto-pick a task):
|
|
20
|
+
|
|
21
|
+
1. Steps that must be completed first (in order), each with its command:
|
|
22
|
+
- Codebase & bottleneck analysis (`codebase-analysed`, `bottlenecks-identified`) → `/owflow:performance-analyze <task-path>`
|
|
23
|
+
2. List available performance-task identifiers (directories under `.owflow/tasks/performance/`) to resume from, if any.
|
|
24
|
+
3. Hint: `Run /owflow:performance <description> to start a task from scratch, or pass a task path/identifier to resume.`
|
|
25
|
+
|
|
26
|
+
### Prerequisites
|
|
27
|
+
|
|
28
|
+
| Required for this skill | Where verified | Produced by |
|
|
29
|
+
| ------------------------------ | ------------------------------------------------------------------------------------------- | ------------------------------------ |
|
|
30
|
+
| State file exists | `<task-path>/orchestrator-state.yml` | `/owflow:performance <desc>` |
|
|
31
|
+
| Bottleneck analysis done | `bottlenecks-identified` in `completed_phases` + `analysis/performance-analysis.md` exists | `/owflow:performance-analyze <task-path>` |
|
|
32
|
+
|
|
33
|
+
1. **Read `orchestrator-state.yml`** from the task path. If missing → mid-pipeline bootstrap ([Missing-state Bootstrap](../orchestrator-framework/references/gate-contract.md), starting slug `spec-written`): `question` — create a fresh standard performance task starting at this step, or decline → print `No performance task found at <path>. Run /owflow:performance <description> to start a task from scratch.` and STOP.
|
|
34
|
+
2. **Skip/resume (artifacts before state)**:
|
|
35
|
+
- If `spec-written` is complete but `implementation/spec.md` is missing → drop the slug and re-run the specification step.
|
|
36
|
+
- If `spec-written` and `spec-audited` are complete: validate `verification/spec-audit.md` exists; missing → drop `spec-audited` and run the audit sub-step; otherwise report existing results and route to the Exit Gate.
|
|
37
|
+
- If only `spec-written` is complete: `options.spec_audit_enabled: false` → report the spec summary and route to the Exit Gate (do not re-ask); otherwise (`null` or `true`) skip directly to the audit sub-step — never re-run Requirements Gathering or Specification Creation.
|
|
38
|
+
3. **Audit skip/resume rule (audit-decision guard)**: the audit question is asked while `options.spec_audit_enabled` is `null`, and only then; a resume with `true` and the audit artifact missing goes straight to the auditor without re-asking. On skip, write `options.spec_audit_enabled: false` and NO `spec-audited` entry; a later resume with `false` does not re-ask. The audit is the conditional activation of this skill's second slug.
|
|
39
|
+
4. **Prerequisite check (presence and content)**: `bottlenecks-identified` in `completed_phases` AND `analysis/performance-analysis.md` exists. If missing → print the blocked block, then STOP:
|
|
40
|
+
- Steps that must be completed first: codebase & bottleneck analysis (`codebase-analysed`, `bottlenecks-identified`).
|
|
41
|
+
- `Run /owflow:performance-analyze <task-path> first.`
|
|
42
|
+
- If no task exists yet: `Run /owflow:performance <description> to start a task from scratch.`
|
|
43
|
+
|
|
44
|
+
## Execute
|
|
45
|
+
|
|
46
|
+
**Read first**: the [Delegation Rules](../orchestrator-framework/references/delegation-rules.md).
|
|
47
|
+
|
|
48
|
+
### Requirements Gathering (part of `spec-written`, inline)
|
|
49
|
+
|
|
50
|
+
1. Present the bottleneck summary from `analysis/performance-analysis.md` (P0-P3 counts and top findings).
|
|
51
|
+
2. `question` for optimization requirements:
|
|
52
|
+
- Which bottleneck priorities to address? (All P0+P1 / P0 only / specific ones)
|
|
53
|
+
- Any constraints? (backward compatibility, memory limits, no new dependencies)
|
|
54
|
+
- Performance targets? (specific response-time or throughput goals, if known)
|
|
55
|
+
3. Save to `analysis/requirements.md`: performance issue description, bottleneck analysis summary, optimization priorities, constraints, targets.
|
|
56
|
+
4. **Standards discovery**: Read `.owflow/docs/INDEX.md` before creating the spec.
|
|
57
|
+
|
|
58
|
+
### Specification Creation (part of `spec-written`, subagent)
|
|
59
|
+
|
|
60
|
+
**ANTI-PATTERN — never write spec.md yourself. "The optimization is straightforward" is NOT a reason to skip delegation.**
|
|
61
|
+
|
|
62
|
+
- ❌ "Let me create the specification..." — STOP. Delegate to `specification-creator`.
|
|
63
|
+
- ❌ "I'll write the spec based on the analysis..." — STOP. Delegate to `specification-creator`.
|
|
64
|
+
|
|
65
|
+
**INVOKE NOW** (Task tool — never the Skill tool; this is an agent): Task tool - `specification-creator` subagent. Pass (Pattern 7 — accumulated context): task_path, task_type="performance", task_description, requirements_path (`analysis/requirements.md`), project_context_paths (INDEX.md + `performance_context.project_doc_paths` from state), `performance_context.task_characteristics`, `performance_context.bottleneck_priorities`, and relevant `performance_context.phase_summaries` (codebase_analysis, bottleneck_analysis, clarifications). Output: `implementation/spec.md`.
|
|
66
|
+
|
|
67
|
+
**SELF-CHECK**: Did you just invoke the Task tool with `specification-creator`? Or did you start writing spec.md yourself? If the latter, STOP and invoke the Task tool.
|
|
68
|
+
|
|
69
|
+
### Diagram Refinement (part of `spec-written`, Skill, content-preserving)
|
|
70
|
+
|
|
71
|
+
Skill tool - `diagrams-mermaid` on `implementation/spec.md`. Add diagrams that clarify bottleneck flows and optimization boundaries without replacing specification prose: `flowchart` (bottleneck → fix path), optional `sequenceDiagram` (key hot path). Missing context → add an explicit open-questions section instead of inventing entities.
|
|
72
|
+
|
|
73
|
+
### Specification Audit (`spec-audited`, conditional)
|
|
74
|
+
|
|
75
|
+
> **ANTI-PATTERN — never audit the specification yourself. "The spec is short" is NOT a reason to skip delegation.**
|
|
76
|
+
>
|
|
77
|
+
> - ❌ "Let me review the spec myself..." — STOP. Delegate to `spec-auditor`.
|
|
78
|
+
> - ❌ "I'll check the spec against the analysis..." — STOP. Delegate to `spec-auditor`.
|
|
79
|
+
|
|
80
|
+
1. If `options.spec_audit_enabled` is already `true` (resume with `verification/spec-audit.md` missing), skip the question and go to step 2. Otherwise `question` — "Run specification audit? (Recommended)" with "Yes, run audit (Recommended)" first. Pre-select the recommended option when the monolith threshold is met: more than 5 optimizations planned or the spec exceeds 50 lines. The user may skip.
|
|
81
|
+
2. If yes: **INVOKE NOW** (Task tool): Task tool - `spec-auditor` subagent. Pass (Pattern 7 — accumulated context): task_path, spec_path (`implementation/spec.md`), plus the bottleneck priorities and spec summary from `performance_context.phase_summaries.specification` for framing. Output: `verification/spec-audit.md`. Display the verdict (pass / pass-with-concerns / fail), issue counts by severity, and top critical findings.
|
|
82
|
+
3. **SELF-CHECK**: Did you just invoke the Task tool with `spec-auditor`? Or did you review the spec yourself? If the latter, STOP and invoke the Task tool.
|
|
83
|
+
|
|
84
|
+
**The audit verdict has no separate state slot** — it is recorded in `performance_context.phase_summaries.specification` (the same slot as the spec summary).
|
|
85
|
+
|
|
86
|
+
## State Update Convention (per step)
|
|
87
|
+
|
|
88
|
+
Apply after EVERY step above:
|
|
89
|
+
|
|
90
|
+
1. **Write immediately** — update `orchestrator-state.yml` as soon as the step completes, appending ONLY the step slug actually performed plus that step's fields. Never batch multiple steps into one end-of-skill write:
|
|
91
|
+
- After the specification step (`spec-written` complete): append `spec-written` to `completed_phases`; set `performance_context.phase_summaries.specification` (approach + scope summary); bump `orchestrator.updated`.
|
|
92
|
+
- After the audit sub-step (only when it ran): append `spec-audited` to `completed_phases`; set `options.spec_audit_enabled: true` and the audit verdict in `performance_context.phase_summaries.specification`; bump `orchestrator.updated`.
|
|
93
|
+
- When the user skips the audit: set `options.spec_audit_enabled: false` and note "audit skipped" in `performance_context.phase_summaries.specification` — **no `spec-audited` entry**.
|
|
94
|
+
2. **Timestamp** — set `orchestrator.updated` to the current UTC timestamp on every write.
|
|
95
|
+
3. **Failures** — if the specification or audit fails and cannot be recovered, do NOT append to `completed_phases`; instead append the step's slug (`spec-written` or `spec-audited`) to `orchestrator.failed_phases` and increment `auto_fix_attempts["<slug>"]`.
|
|
96
|
+
4. **Validate** — after every write, re-read the file to confirm values, then run the `verify_template` tool with `filePath: <task-path>/orchestrator-state.yml`, `templateName: orchestrator-state-performance.yml`. Fix any reported issue immediately before proceeding.
|
|
97
|
+
5. **Final check** — before the Exit Gate, one consolidated re-read + `verify_template` run to confirm the full state matches everything performed in this session.
|
|
98
|
+
|
|
99
|
+
## Recovery
|
|
100
|
+
|
|
101
|
+
| Step | Max Attempts | Strategy |
|
|
102
|
+
| --------------------------------- | ------------ | ------------------------------------------------------------------------------- |
|
|
103
|
+
| Specification (`spec-written`) | 2 | Regenerate spec with adjusted requirements |
|
|
104
|
+
| Specification Audit (`spec-audited`) | 2 | Re-run the auditor; on repeated failure report the verdict and offer the skip path |
|
|
105
|
+
|
|
106
|
+
## Exit Gate
|
|
107
|
+
|
|
108
|
+
Present results, get user confirmation, then hand off (see [Gate Contract](../orchestrator-framework/references/gate-contract.md)). Never auto-invoke the next skill.
|
|
109
|
+
|
|
110
|
+
### Results box
|
|
111
|
+
|
|
112
|
+
```markdown
|
|
113
|
+
## ✅ PERFORMANCE SPEC COMPLETE — <spec title>
|
|
114
|
+
|
|
115
|
+
**Approach** — [optimization approach in 1 line]
|
|
116
|
+
**Scope** — [N included / M excluded]
|
|
117
|
+
**Audit** — [✅ pass / ⚠ pass-with-concerns / ❌ fail / skipped]: [0 critical / N major / N minor]
|
|
118
|
+
**Priorities** — [P0/P1/P2/P3 addressed]
|
|
119
|
+
|
|
120
|
+
**Artifacts**
|
|
121
|
+
|
|
122
|
+
- `analysis/requirements.md`
|
|
123
|
+
- `implementation/spec.md`
|
|
124
|
+
- `verification/spec-audit.md` [conditional]
|
|
125
|
+
```
|
|
126
|
+
|
|
127
|
+
### Results-acceptance question
|
|
128
|
+
|
|
129
|
+
Use `question` — "Are these results correct?" with options:
|
|
130
|
+
|
|
131
|
+
- **Accept** — the specification is good; continue.
|
|
132
|
+
- **Adjust** — regenerate the spec with the user's corrections (priorities, constraints, targets), update state and artifacts, re-present the results box.
|
|
133
|
+
- **Discuss** — walk through a specific part of the spec (scope boundaries, optimization approach, audit findings) in more depth; then re-ask.
|
|
134
|
+
- **Stop here** — print the resume command (`/owflow:performance-spec <task-path>`) and end.
|
|
135
|
+
|
|
136
|
+
### Next steps (after Accept)
|
|
137
|
+
|
|
138
|
+
- `→ /owflow:performance-plan <task-path>` — `required` next: breaks the approved spec into grouped, dependency-ordered task groups. Remaining after: implement → verify → finalize.
|
|
139
|
+
|
|
140
|
+
**Other options**:
|
|
141
|
+
|
|
142
|
+
- `/owflow:reviews-spec-audit <task-path>` — `optional` — standalone spec re-audit; does not advance phases (verify results, then re-run `/owflow:performance-spec` adjustments if needed)
|
|
143
|
+
- `/owflow:goal-performance <task-path>` — `optional` shortcut: runs all remaining steps in one loop (plan → implement → verify → finalize)
|
|
144
|
+
|
|
145
|
+
Then STOP.
|
|
@@ -0,0 +1,164 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: owflow:performance-verify
|
|
3
|
+
description: Performance — verification options prompt, comprehensive implementation verification, and user-driven fix loop. Continues with performance-finalize.
|
|
4
|
+
argument-hint: "[task-path-or-identifier]"
|
|
5
|
+
user-invocable: true
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Performance Verify — Verification Options & Issue Resolution (options-chosen, verification-done)
|
|
9
|
+
|
|
10
|
+
Work step of the performance workflow. Lets the user pick which additional verification checks run, writes the chosen `options.*` to state BEFORE verification starts, then delegates comprehensive verification with a fix-then-reverify loop. State lives in `orchestrator-state.yml` — this skill reads it on entry and writes results on exit.
|
|
11
|
+
|
|
12
|
+
## Entry Gate
|
|
13
|
+
|
|
14
|
+
Resolve the argument BEFORE anything else (see [Gate Contract](../orchestrator-framework/references/gate-contract.md)). The argument may be:
|
|
15
|
+
|
|
16
|
+
- **Path** (absolute or project-relative) to the task directory — use as-is.
|
|
17
|
+
- **Identifier** — exact directory name inside `.owflow/tasks/performance/` (e.g., `2026-10-02-api-latency`); resolve to its path.
|
|
18
|
+
- **Description** — anything else (free text) is treated as a new performance task description: ask via `question` whether to start a fresh standard task at this step (mid-pipeline bootstrap) or route through `/owflow:performance <description>`; on decline, print the blocked block and STOP.
|
|
19
|
+
- If the argument is **missing**, the path does **not exist**, or matches **no identifier** → print the blocked block, then STOP (never guess or auto-pick a task):
|
|
20
|
+
|
|
21
|
+
1. Steps that must be completed first (in order), each with its command:
|
|
22
|
+
- Codebase & bottleneck analysis (`codebase-analysed`, `bottlenecks-identified`) → `/owflow:performance-analyze <task-path>`
|
|
23
|
+
- Requirements, specification & conditional audit (`spec-written`, `spec-audited`) → `/owflow:performance-spec <task-path>`
|
|
24
|
+
- Implementation planning (`plan-created`) → `/owflow:performance-plan <task-path>`
|
|
25
|
+
- Implementation (`implementation-done`) → `/owflow:performance-implement <task-path>`
|
|
26
|
+
2. List available performance-task identifiers (directories under `.owflow/tasks/performance/`) to resume from, if any.
|
|
27
|
+
3. Hint: `Run /owflow:performance <description> to start a task from scratch, or pass a task path/identifier to resume.`
|
|
28
|
+
|
|
29
|
+
### Prerequisites
|
|
30
|
+
|
|
31
|
+
| Required for this skill | Where verified | Produced by |
|
|
32
|
+
| ----------------------- | -------------------------------------------------------------------- | ----------------------------------------- |
|
|
33
|
+
| State file exists | `<task-path>/orchestrator-state.yml` | `/owflow:performance <desc>` |
|
|
34
|
+
| Implementation done | `implementation-done` in `completed_phases` + `implementation/work-log.md` exists | `/owflow:performance-implement <task-path>` |
|
|
35
|
+
|
|
36
|
+
1. **Read `orchestrator-state.yml`** from the task path. If missing → mid-pipeline bootstrap ([Missing-state Bootstrap](../orchestrator-framework/references/gate-contract.md), starting slug `options-chosen`): `question` — create a fresh standard performance task starting at this step, or decline → print `No performance task found at <path>. Run /owflow:performance <description> to start a task from scratch.` and STOP.
|
|
37
|
+
2. **Skip/resume + options idempotence rule**: if `options-chosen` is in `completed_phases` AND at least one `orchestrator.options.*` review flag is non-null, the options are already chosen — report them and route straight to the verification-done step; do NOT re-ask. If `verification-done` is also complete (validated against `verification/implementation-verification.md`), report existing results and route to the Exit Gate; if that artifact is missing, drop `verification-done` and re-run verification.
|
|
38
|
+
3. **Prerequisite check (presence and content)**: `implementation-done` in `completed_phases` AND `implementation/work-log.md` exists. If missing → print the blocked block, then STOP:
|
|
39
|
+
- Steps that must be completed first: implementation (`implementation-done`).
|
|
40
|
+
- `Run /owflow:performance-implement <task-path> first` (or the command for the earliest missing earlier step: `/owflow:performance-analyze`, `/owflow:performance-spec`, or `/owflow:performance-plan`).
|
|
41
|
+
- If no task exists yet: `Run /owflow:performance <description> to start a task from scratch.`
|
|
42
|
+
|
|
43
|
+
## Execute
|
|
44
|
+
|
|
45
|
+
**Read first**: the [Delegation Rules](../orchestrator-framework/references/delegation-rules.md) and [Issue Resolution](../orchestrator-framework/references/orchestrator-patterns.md) (Section 6).
|
|
46
|
+
|
|
47
|
+
### Verification Options (`options-chosen`, inline)
|
|
48
|
+
|
|
49
|
+
**Step 1**: Display the verification plan:
|
|
50
|
+
|
|
51
|
+
```
|
|
52
|
+
Verification Plan:
|
|
53
|
+
Obligatory (always run):
|
|
54
|
+
✓ Completeness check
|
|
55
|
+
✓ Test suite (skipped — passed during implementation; re-enabled after fixes)
|
|
56
|
+
|
|
57
|
+
Recommended (adjustable):
|
|
58
|
+
✓ Code review — quality and security analysis
|
|
59
|
+
✓ Pragmatic review — detects over-engineering
|
|
60
|
+
✓ Reality check — validates the optimization solves the problem
|
|
61
|
+
✓ Production readiness — deployment readiness checks
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
**Step 2**: `question` (multi-select) — "Which additional verification checks?" Options, pre-selected from state where non-null: "Code review (Recommended)", "Pragmatic review (Recommended)", "Reality check (Recommended)", "Production readiness (Recommended)".
|
|
65
|
+
|
|
66
|
+
**Step 3**: Write the chosen flags to `orchestrator.options.*` (`code_review_enabled`, `pragmatic_review_enabled`, `reality_check_enabled`, `production_check_enabled`) and auto-set `skip_test_suite: true` (safe ONLY because `implementation-plan-executor` already ended with a full test-suite run; it is cleared before re-verification if fixes are applied). **WRITE `options.*` BEFORE the verification step below invokes `implementation-verifier`** — the verifier reads these flags from state and executes them without re-prompting; this is the one ordering constraint it cannot recover from.
|
|
67
|
+
|
|
68
|
+
**State write**: append `options-chosen` to `completed_phases`; write the chosen `options.*` and `skip_test_suite`; bump `orchestrator.updated`; re-read + `verify_template` (see State Update Convention).
|
|
69
|
+
|
|
70
|
+
### Verification & Issue Resolution (`verification-done`)
|
|
71
|
+
|
|
72
|
+
**Step 1**: **INVOKE NOW** (Skill tool — never the Task tool; this skill spawns its own subagents): Skill tool - `implementation-verifier`. Pass: task_path, task_description, the chosen verification options, and `verification_context` if re-verifying. The verifier reads `options.*` from state and executes the enabled reviews without re-prompting.
|
|
73
|
+
|
|
74
|
+
**SELF-CHECK**: Did you just invoke the Skill tool with `implementation-verifier`? Or did you start running checks yourself? If the latter, STOP and invoke the Skill tool.
|
|
75
|
+
|
|
76
|
+
**Step 2**: Display the detailed issue breakdown grouped by category and severity:
|
|
77
|
+
|
|
78
|
+
```
|
|
79
|
+
Verification Results:
|
|
80
|
+
Critical ([N]):
|
|
81
|
+
- [category]: [description] — [file:line] [fixable/manual]
|
|
82
|
+
Warning ([N]):
|
|
83
|
+
- [category]: [description] — [file:line] [fixable/manual]
|
|
84
|
+
Info ([N]):
|
|
85
|
+
- [description] (listed for awareness, not actionable)
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
**Step 3**: Gate on status — `passed` → skip to the state write. `passed_with_issues` or `failed` → fix loop (Step 4).
|
|
89
|
+
|
|
90
|
+
**Step 4**: User-driven fix loop (max 3 iterations):
|
|
91
|
+
|
|
92
|
+
1. Present critical + warning issues as a numbered list.
|
|
93
|
+
2. `question` — "Which issues should I fix?" Options: "Fix all fixable issues" / "Let me choose specific issues" / "Skip fixes, proceed as-is".
|
|
94
|
+
3. Fix the selected issues; **immediately** log each to `verification_context.fixes_applied` in state (not deferred to the end).
|
|
95
|
+
4. After fixes: set `skip_test_suite: false` (code changed, tests must re-run).
|
|
96
|
+
5. `question` — "Re-run verification to check fixes?" → re-invoke `implementation-verifier` → back to Step 2, or "No, proceed to next step".
|
|
97
|
+
6. **Immediately** update `verification_context.reverify_count` and `verification_context.last_status` in state after each verifier run and after each fix-loop iteration.
|
|
98
|
+
|
|
99
|
+
**Exit conditions**: no critical issues remain → proceed; the user explicitly chooses to proceed with issues → proceed with issues logged; max 3 iterations → `question` "Proceed with known issues?" / "Stop workflow". **MUST NOT proceed with unresolved critical issues unless the user explicitly approves.**
|
|
100
|
+
|
|
101
|
+
**State write**: append `verification-done` to `completed_phases` only at skill exit — status `passed`, or user-approved proceed with issues logged. Bump `orchestrator.updated`. On failure: append `verification-done` to `failed_phases`, increment `auto_fix_attempts["verification-done"]`. Then re-read state + run `verify_template`.
|
|
102
|
+
|
|
103
|
+
## State Update Convention (per step)
|
|
104
|
+
|
|
105
|
+
Apply after EVERY step above:
|
|
106
|
+
|
|
107
|
+
1. **Write immediately** — update `orchestrator-state.yml` as soon as the step completes, appending ONLY the step slug actually performed plus that step's fields. Never defer writes to the end of the skill:
|
|
108
|
+
- Append `options-chosen` with the chosen `options.*` and `skip_test_suite` right after the options prompt, before verification starts.
|
|
109
|
+
- Append `verification-done` only at skill exit: status `passed`, or user-approved proceed with issues logged.
|
|
110
|
+
- Update `verification_context.last_status`, `issues_found`, `fixes_applied`, and `reverify_count` immediately after each `implementation-verifier` run and after each fix-loop iteration, so an interruption loses nothing.
|
|
111
|
+
2. **Timestamp** — set `orchestrator.updated` to the current UTC timestamp on every write.
|
|
112
|
+
3. **Failures** — if `implementation-verifier` itself fails or the workflow stops with unresolved critical issues, do NOT append `verification-done` to `completed_phases`; append it to `orchestrator.failed_phases` and increment `auto_fix_attempts["verification-done"]`.
|
|
113
|
+
4. **Validate** — after every write, re-read the file to confirm values, then run the `verify_template` tool with `filePath: <task-path>/orchestrator-state.yml`, `templateName: orchestrator-state-performance.yml`. Fix any reported issue immediately before proceeding.
|
|
114
|
+
5. **Final check** — before the Exit Gate, one consolidated re-read + `verify_template` run to confirm the full state matches everything performed in this session.
|
|
115
|
+
|
|
116
|
+
## Recovery
|
|
117
|
+
|
|
118
|
+
| Step | Max Attempts | Strategy |
|
|
119
|
+
| --------------------------------------------- | ------------ | ----------------------------------------------------------------------------------------- |
|
|
120
|
+
| Verification Options (`options-chosen`) | 1 | Re-ask the multi-select once if the answer is unusable; the recommended defaults stay |
|
|
121
|
+
| Verification & Issue Resolution (`verification-done`) | 3 | Fix-then-reverify cycles; after 3 iterations ask the user to proceed with known issues or stop |
|
|
122
|
+
|
|
123
|
+
## Exit Gate
|
|
124
|
+
|
|
125
|
+
Present results, get user confirmation, then hand off (see [Gate Contract](../orchestrator-framework/references/gate-contract.md)). Never auto-invoke the next skill.
|
|
126
|
+
|
|
127
|
+
### Results box
|
|
128
|
+
|
|
129
|
+
```markdown
|
|
130
|
+
## ✅ PERFORMANCE VERIFY COMPLETE — <task name>
|
|
131
|
+
|
|
132
|
+
**Overall status** — [✅ passed / ⚠ passed_with_issues / ❌ failed]
|
|
133
|
+
**Issues found** — [total] ([critical] C / [warning] W / [info] I)
|
|
134
|
+
**Fixed** — [count]
|
|
135
|
+
**Remaining** — [by severity]
|
|
136
|
+
|
|
137
|
+
**Artifacts**
|
|
138
|
+
|
|
139
|
+
- `verification/implementation-verification.md`
|
|
140
|
+
- `verification/code-review-report.md` [if run]
|
|
141
|
+
- `verification/pragmatic-review.md` [if run]
|
|
142
|
+
- `verification/reality-check.md` [if run]
|
|
143
|
+
- `verification/production-readiness-report.md` [if run]
|
|
144
|
+
```
|
|
145
|
+
|
|
146
|
+
### Results-acceptance question
|
|
147
|
+
|
|
148
|
+
Use `question` — "Are these results correct?" with options:
|
|
149
|
+
|
|
150
|
+
- **Accept** — verification outcome is good (including approved proceed-with-issues); continue.
|
|
151
|
+
- **Adjust** — run additional fixes and/or another verification round (within the fix-loop limits), then re-present the results box.
|
|
152
|
+
- **Discuss** — walk through specific findings (issue details, fixability assessment, measurement caveats) in more depth; then re-ask.
|
|
153
|
+
- **Stop here** — print the resume command (`/owflow:performance-verify <task-path>`) and end.
|
|
154
|
+
|
|
155
|
+
### Next steps (after Accept)
|
|
156
|
+
|
|
157
|
+
- `→ /owflow:performance-finalize <task-path>` — `required` to close the workflow: final summary, commit guidance, and post-completion measurement hints. Remaining after: none — workflow ends.
|
|
158
|
+
|
|
159
|
+
**Other options**:
|
|
160
|
+
|
|
161
|
+
- `/owflow:reviews-code <task-path>` / `/owflow:reviews-pragmatic <task-path>` — `optional` — standalone re-runs of individual reviews; do not advance phases
|
|
162
|
+
- `/owflow:goal-performance <task-path>` — `optional` shortcut: finishes the remaining step in one loop (finalize)
|
|
163
|
+
|
|
164
|
+
Then STOP.
|
|
@@ -1,18 +1,27 @@
|
|
|
1
1
|
orchestrator:
|
|
2
2
|
started_phase: null
|
|
3
|
+
entry_point: null
|
|
3
4
|
completed_phases: []
|
|
4
5
|
failed_phases: []
|
|
5
6
|
auto_fix_attempts:
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
7
|
+
state-analysed: 0
|
|
8
|
+
target-planned: 0
|
|
9
|
+
strategy-specified: 0
|
|
10
|
+
plan-created: 0
|
|
11
|
+
migration-executed: 0
|
|
12
|
+
options-chosen: 0
|
|
13
|
+
verification-done: 0
|
|
14
|
+
issues-resolved: 0
|
|
15
|
+
docs-generated: 0
|
|
16
|
+
task-completed: 0
|
|
14
17
|
options:
|
|
15
|
-
docs_enabled:
|
|
18
|
+
docs_enabled: null
|
|
19
|
+
skip_test_suite: null
|
|
20
|
+
code_review_enabled: null
|
|
21
|
+
code_review_scope: null
|
|
22
|
+
pragmatic_review_enabled: null
|
|
23
|
+
production_check_enabled: null
|
|
24
|
+
reality_check_enabled: null
|
|
16
25
|
created: "YYYY-MM-DDTHH:MM:SSZ"
|
|
17
26
|
updated: "YYYY-MM-DDTHH:MM:SSZ"
|
|
18
27
|
task_path: null
|
|
@@ -40,6 +49,22 @@ migration_context:
|
|
|
40
49
|
breaking_changes: []
|
|
41
50
|
rollback_plan_created: false
|
|
42
51
|
dual_run_configured: false
|
|
52
|
+
clarifications_resolved: null
|
|
53
|
+
phase_summaries:
|
|
54
|
+
analyze:
|
|
55
|
+
summary: null
|
|
56
|
+
target:
|
|
57
|
+
summary: null
|
|
58
|
+
spec:
|
|
59
|
+
summary: null
|
|
60
|
+
plan:
|
|
61
|
+
summary: null
|
|
62
|
+
implement:
|
|
63
|
+
summary: null
|
|
64
|
+
verify:
|
|
65
|
+
summary: null
|
|
66
|
+
fix:
|
|
67
|
+
summary: null
|
|
43
68
|
|
|
44
69
|
external_research:
|
|
45
70
|
performed: false
|
|
@@ -50,6 +75,21 @@ external_research:
|
|
|
50
75
|
verification_context:
|
|
51
76
|
last_status: null
|
|
52
77
|
issues_found: null
|
|
78
|
+
compatibility_status: null
|
|
53
79
|
fixes_applied: []
|
|
54
80
|
decisions_made: []
|
|
55
81
|
reverify_count: 0
|
|
82
|
+
|
|
83
|
+
migration_outputs:
|
|
84
|
+
current_state_analysis: null
|
|
85
|
+
clarifications: null
|
|
86
|
+
target_state_plan: null
|
|
87
|
+
requirements: null
|
|
88
|
+
spec: null
|
|
89
|
+
rollback_plan: null
|
|
90
|
+
dual_run_plan: null
|
|
91
|
+
implementation_plan: null
|
|
92
|
+
work_log: null
|
|
93
|
+
implementation_verification: null
|
|
94
|
+
compatibility_test_results: null
|
|
95
|
+
migration_guide: null
|
|
@@ -1,17 +1,18 @@
|
|
|
1
1
|
orchestrator:
|
|
2
2
|
started_phase: null
|
|
3
|
+
entry_point: null
|
|
3
4
|
completed_phases: []
|
|
4
5
|
failed_phases: []
|
|
5
6
|
auto_fix_attempts:
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
7
|
+
codebase-analysed: 0
|
|
8
|
+
bottlenecks-identified: 0
|
|
9
|
+
spec-written: 0
|
|
10
|
+
spec-audited: 0
|
|
11
|
+
plan-created: 0
|
|
12
|
+
implementation-done: 0
|
|
13
|
+
options-chosen: 0
|
|
14
|
+
verification-done: 0
|
|
15
|
+
task-completed: 0
|
|
15
16
|
options:
|
|
16
17
|
spec_audit_enabled: null
|
|
17
18
|
skip_test_suite: true
|
|
@@ -39,11 +40,21 @@ performance_context:
|
|
|
39
40
|
p1: 0
|
|
40
41
|
p2: 0
|
|
41
42
|
p3: 0
|
|
43
|
+
project_doc_paths: []
|
|
44
|
+
task_characteristics:
|
|
45
|
+
has_reproducible_defect: false
|
|
46
|
+
modifies_existing_code: false
|
|
47
|
+
creates_new_entities: false
|
|
48
|
+
involves_data_operations: false
|
|
49
|
+
ui_heavy: false
|
|
42
50
|
phase_summaries:
|
|
43
51
|
codebase_analysis: { key_files: [], summary: null }
|
|
44
52
|
bottleneck_analysis:
|
|
45
53
|
{ bottlenecks: [], summary: null, user_data_incorporated: false }
|
|
46
54
|
specification: { summary: null }
|
|
55
|
+
clarifications: { summary: null }
|
|
56
|
+
planning: { summary: null }
|
|
57
|
+
implementation: { summary: null }
|
|
47
58
|
|
|
48
59
|
verification_context:
|
|
49
60
|
last_status: null
|