wize-dev-kit 0.14.0 → 0.16.0

package/src/method-skills/4-implementation/wize-code-review/customize.toml

@@ -1,21 +0,0 @@
-# Wize Dev Kit — overrides for the built-in workflow "wize-code-review".
-# DO NOT EDIT in the installed kit; copy to .wize/custom/workflows/wize-code-review/
-# for project-level overrides.
-
-[workflow]
-
-# Steps to run before standard activation (config load, greet).
-activation_steps_prepend = []
-
-# Steps to run after greet but before the workflow begins.
-activation_steps_append = []
-
-# Persistent facts the workflow keeps in mind for the whole run.
-persistent_facts = [
-  "file:{project-root}/.wize/knowledge/document-project/conventions.md",
-]
-
-# Scalar executed when the workflow reaches its final step,
-# after review findings are presented and sprint status is synced.
-# Override wins. Leave empty for no custom post-completion behavior.
-on_complete = ""

package/src/method-skills/4-implementation/wize-code-review/steps/step-01-gather-context.md

@@ -1,64 +0,0 @@
----
-diff_output: ''
-spec_file: ''
-review_mode: ''
-story_key: ''
----
-
-# Step 1: Gather Context
-
-## Rules
-
-- Speak in `{communication_language}`.
-- The prompt that triggered this workflow IS the intent.
-- Do not modify any files in this step. Read-only.
-
-## Instructions
-
-1. **Find the review target.** Check in this order and stop as soon as the target is identified:
-
-   **Tier 1 — Explicit argument.**
-   Did the user pass a PR, commit SHA, branch, spec file, or diff source?
-   - PR reference → resolve to branch/commit via `gh pr view`.
-   - Commit or branch → use directly.
-   - Spec file → set `{spec_file}` to the path. Check its frontmatter for `baseline_commit`.
-   - Diff-mode keywords: `staged`, `uncommitted`, `branch diff`, `commit range`, `this diff`.
-
-   **Tier 2 — Recent conversation.**
-   Look for refs in the last few messages.
-
-   **Tier 3 — Sprint tracking.**
-   Look for `*sprint-status*` files and find stories with status `review`.
-
-   **Tier 4 — Current git state.**
-   If not on the default branch, confirm whether to review the current branch.
-
-   **Tier 5 — Ask.**
-   Present options: uncommitted changes, staged changes, branch diff, commit range, provided diff.
-
-2. **Construct `{diff_output}`.**
-   - Staged only: `git diff --cached`
-   - Uncommitted: `git diff HEAD`
-   - Branch diff: `git diff <base>..<branch>`
-   - Commit range: `git diff <from>..<to>`
-   - Provided diff: validate and use verbatim
-   - File list: `git diff HEAD -- <files...>`, with untracked files included via `git diff --no-index /dev/null <path>`
-
-   If `{diff_output}` is empty, halt and say so.
-
-3. **Set the spec context.**
-   - If `{spec_file}` is set and readable, set `{review_mode}` = `"full"`.
-   - Otherwise ask: "Is there a spec or story file that provides context for these changes?"
-     - Yes → set `{spec_file}`, verify it, set `{review_mode}` = `"full"`.
-     - No → set `{review_mode}` = `"no-spec"`.
-
-4. **Sanity check.**
-   If the diff exceeds ~3000 lines, warn and offer to chunk.
-
-### Checkpoint
-
-Present a summary: diff stats, `{review_mode}`, loaded spec/context docs. Halt and wait for confirmation to proceed.
-
-## Next
-
-Read fully and follow `./step-02-review.md`.

package/src/method-skills/4-implementation/wize-code-review/steps/step-02-review.md

@@ -1,40 +0,0 @@
----
-failed_layers: ''
----
-
-# Step 2: Review
-
-## Rules
-
-- Speak in `{communication_language}`.
-- The Blind Hunter subagent receives **only** the diff — no project context.
-- The Edge Case Hunter subagent receives the diff and project read access.
-- The Acceptance Auditor subagent receives the diff, spec, and context docs.
-- All review subagents run at the same model capability as the current session.
-
-## Instructions
-
-This step is an instance of Wizer's subagent fan-out pattern (see `wize-orchestrator` persona): name, scope, dispatch on whatever the current harness natively supports, tolerate partial failure.
-
-1. If `{review_mode}` = `"no-spec"`, note: "Acceptance Auditor skipped — no spec file provided."
-
-2. Launch parallel subagents without conversation context:
-
-   - **Blind Hunter** — receives `{diff_output}` only. Invoke via `wize-review-adversarial`.
-     Prompt: "Review this diff cynically. Assume problems exist. Find at least ten issues. Output as a Markdown list with one-line titles."
-
-   - **Edge Case Hunter** — receives `{diff_output}` and read access to the project. Invoke via `wize-review-edge-case-hunter`.
-     Prompt: "Walk every branching path and boundary condition in this diff. Report only unhandled edge cases as a JSON array."
-
-   - **Acceptance Auditor** (only if `{review_mode}` = `"full"`) — receives `{diff_output}`, `{spec_file}` content, and context docs.
-     Prompt: "Review this diff against the spec. Check for violations of acceptance criteria, deviations from spec intent, and missing behavior. Output findings as a Markdown list with AC/constraint reference and evidence."
-
-3. If subagents are unavailable, generate prompt files in `{implementation_artifacts}` and halt, asking the user to run each in a separate session.
-
-4. If any subagent fails, times out, or returns empty, append the layer name to `{failed_layers}` and proceed with findings from the remaining layers.
-
-5. Collect all findings from completed layers.
-
-## Next
-
-Read fully and follow `./step-03-triage.md`.

package/src/method-skills/4-implementation/wize-code-review/steps/step-03-triage.md

@@ -1,43 +0,0 @@
-# Step 3: Triage
-
-## Rules
-
-- Speak in `{communication_language}`.
-- Be precise. When uncertain between categories, prefer the more conservative classification.
-
-## Instructions
-
-1. **Normalize** findings into a common format. Expected input formats:
-   - Blind Hunter: Markdown list of descriptions.
-   - Edge Case Hunter: JSON array with `location`, `trigger_condition`, `guard_snippet`, `potential_consequence`.
-   - Acceptance Auditor: Markdown list with title, AC/constraint reference, and evidence.
-
-   Convert all to a unified list with:
-   - `id` — sequential integer
-   - `source` — `blind`, `edge`, `auditor`, or merged (`blind+edge`, etc.)
-   - `title` — one-line summary
-   - `detail` — full description
-   - `location` — file and line reference if available
-
-2. **Deduplicate.** Merge findings that describe the same issue:
-   - Use the most specific finding as the base (prefer Edge Case Hunter JSON with location).
-   - Append unique detail, reasoning, or locations from other findings.
-   - Set `source` to merged sources.
-
-3. **Classify** each finding into exactly one bucket:
-   - **decision_needed** — ambiguous choice requiring human input. Only possible if `{review_mode}` = `"full"`.
-   - **patch** — code issue fixable without human input.
-   - **defer** — pre-existing issue not caused by this change.
-   - **dismiss** — noise, false positive, or handled elsewhere.
-
-   If `{review_mode}` = `"no-spec"` and a finding would be `decision_needed`, reclassify as `patch` or `defer`.
-
-4. **Drop** all `dismiss` findings. Record the dismiss count.
-
-5. If `{failed_layers}` is non-empty, report which layers failed. If zero findings remain and layers failed, warn the user that the review may be incomplete.
-
-6. If zero findings remain after triage, state: "✅ Clean review — all layers passed."
-
-## Next
-
-Read fully and follow `./step-04-present.md`.

package/src/method-skills/4-implementation/wize-code-review/steps/step-04-present.md

@@ -1,100 +0,0 @@
----
-deferred_work_file: '{implementation_artifacts}/deferred-work.md'
----
-
-# Step 4: Present and Act
-
-## Rules
-
-- Speak in `{communication_language}`.
-- When `{spec_file}` is set, always write findings to the story file before offering action choices.
-- `decision_needed` findings must be resolved before handling `patch` findings.
-
-## Instructions
-
-### 1. Clean review shortcut
-
-If zero findings remain after triage, state that and proceed to section 6 (Sprint Status Update).
-
-### 2. Write findings to the story file
-
-If `{spec_file}` exists and contains a Tasks/Subtasks section, append a `### Review Findings` subsection in this order:
-
-1. `decision_needed` (unchecked):
-   ```
-   - [ ] [Review][Decision] <Title> — <Detail>
-   ```
-2. `patch` (unchecked):
-   ```
-   - [ ] [Review][Patch] <Title> [<file>:<line>]
-   ```
-3. `defer` (checked):
-   ```
-   - [x] [Review][Defer] <Title> [<file>:<line>] — deferred, pre-existing
-   ```
-
-Also append each `defer` finding to `{deferred_work_file}` under `## Deferred from: code review ({date})`.
-
-### 3. Present summary
-
-```
-Code review complete.
-- decision_needed: {D}
-- patch: {P}
-- defer: {W}
-- dismissed: {R}
-```
-
-If `{spec_file}` is set, add: "Findings written to `{spec_file}`."
-
-### 4. Resolve decision_needed findings
-
-Present each `decision_needed` finding and ask the user to decide. Once resolved, each becomes a `patch`, `defer`, or is dismissed.
-
-If deferred, ask for a one-line reason and append it to both the story file bullet and the deferred-work file.
-
-### 5. Handle patch findings
-
-If `patch` findings exist, ask:
-
-```
-How would you like to handle the {P} patch findings?
-1. Apply every patch — fix all now, no per-finding confirmation.
-2. Leave as action items — they are already in the story file (only if spec_file set).
-3. Walk through each patch — show details before deciding.
-```
-
-Wait for the numbered choice. Do not proceed until selected.
-
-- **Apply every patch**: apply all patch findings. Afterward, present a summary of changes and check off patch items in the story file if applicable.
-- **Leave as action items**: done.
-- **Walk through each patch**: present each finding with detail and suggested fix, then re-offer the menu.
-
-### 6. Update story status and sync sprint tracking
-
-Skip if `{spec_file}` is not set.
-
-Determine `{new_status}`:
-- If all `decision_needed` and `patch` findings are resolved and no unresolved issues remain → `done`
-- If patch findings were left as action items or unresolved issues remain → `in-progress`
-
-Update the story file status and save it.
-
-If `{story_key}` is set and a sprint-status file exists, update the matching `development_status` entry.
-
-### 7. Next steps
-
-Present options:
-
-```
-What would you like to do next?
-1. Start the next story — run wize-dev-story to pick up the next ready-for-dev story.
-2. Re-run code review — address findings and review again.
-3. Done — end the workflow.
-```
-
-Wait for the numbered choice.
-
-## On complete
-
-Run `{workflow.on_complete}` if non-empty.

package/src/method-skills/4-implementation/wize-correct-course/workflow.md

@@ -1,93 +0,0 @@
----
-
-code: wize-correct-course
-description: "Use quando o projeto desviar do plano e precisar de correção de curso com decisão documentada."
-name: Correct Course
-phase: 4-implementation
-owner: wize-agent-pm   # Maria Hill, with wize-orchestrator
-status: ready
----
-
-# Correct Course
-
-**Goal.** React when a sprint drifts. Detect the deviation, classify the cause, propose one of three corrective moves (cut scope, re-route, escalate), and update `sprint-status.yaml` after the user confirms.
-
-Maria Hill chairs. Wizer is on call for cross-cutting decisions. The human always confirms the action.
-
-## When to run
-
-- `wize-sprint-status` flagged a risk: "slipping" or "at risk".
-- The team says "we won't make it" during a stand-up.
-- A story's TEA gate came back as `FAIL` mid-sprint.
-- An external event (incident, vendor outage) consumed capacity.
-- **Automatic trigger:** any skill that completes step 7.5 (loop verification) and hits the max-cycles guard escalates to Wizer, who runs this skill.
-- **Staleness monitor:** if `wize-sprint-status` has not been updated in 2+ days, Wizer auto-runs this skill on session start (detected in step 1).
-
-## Inputs
-
-- `.wize/implementation/sprint-status.yaml`
-- `.wize/implementation/tea/{epic}/{story}/gate.md` (when a gate failed)
-- `.wize/knowledge/document-project/risk-spots.md` (for context on known risks)
-- A free-form reason from the user: chat message, stand-up note, or incident link.
-
-## Output
-
-- Updated `.wize/implementation/sprint-status.yaml` (statuses changed, items deferred).
-- One-line entry in `.wize/implementation/course-corrections.md` with date, cause, action, owner.
-
-## Steps
-
-### 1. Detect
-
-Wizer pulls the latest status file. If `last_updated` is older than 2 days, the sprint is stale. Mark this as risk #0: stale signal.
-
-### 2. Classify
-
-Pick exactly one cause:
-
-- **Cut scope.** Story turned out larger than one PR, or a non-essential AC can be deferred.
-- **Re-route.** Story needs a different agent (e.g., Mantis for UX) or skill (e.g., `wize-investigate` for a regression).
-- **Escalate.** Story needs more hands, or a decision outside the team.
-
-A sprint can have multiple causes; the workflow handles one per run. Re-run for additional causes.
-
-### 3. Propose
-
-For each cause, propose 1–3 specific actions. Each action is bounded: a story ID to move, a date to defer to, or a person to page. No vague "communicate more" — that’s not an action.
-
-### 4. Confirm with the human
-
-List the actions; the human picks which to apply. Apply only what the human approved.
-
-### 5. Update the sprint
-
-For each approved action:
-
-- Change `sprint-status.yaml` statuses (e.g., story from `in-progress` → `backlog` if deferred).
-- Append a row to `course-corrections.md` with `date`, `cause`, `action`, `owner`.
-
-### 6. Hand off
-
-Notify the next workflow that should run (usually `wize-sprint-status` to confirm the new state, or `wize-dev-story` to continue the remaining work).
-
-## Output template — `course-corrections.md`
-
-```markdown
-# Course corrections
-
-| Date | Sprint | Cause | Action | Owner |
-|---|---|---|---|---|
-| 2026-06-15 | 4 | cut scope | E04-S02 split into S02a + S02b; S02b deferred to S5 | Hill |
-| 2026-06-15 | 4 | escalate | Paged Tony to unblock E04-S01 (waiting on ADR-010) | Wizer |
-```
-
-## Anti-patterns Hill rejects
-
-- Cutting scope without confirming the trade-off with the user.
-- Moving a story to `done` to "stop tracking it" when it isn’t actually done.
-- Re-routing to an agent who doesn’t have the context (always include a 3-sentence brief).
-- Escalating without naming a specific decision blocker.
-
-## Hand-off
-
-> "Course correction applied at `.wize/implementation/course-corrections.md`. Sprint {N} updated. Run `/wize-sprint-status` to confirm the new state."

package/src/method-skills/4-implementation/wize-investigate/workflow.md

@@ -1,123 +0,0 @@
----
-
-code: wize-investigate
-description: "Use quando um bug ou comportamento inesperado surgir e precisar de investigação estruturada com root cause analysis."
-name: Investigate
-phase: 4-implementation
-owner: wize-agent-dev   # Shuri (+ wize-agent-test-architect Hawkeye on call)
-status: ready
----
-
-# Investigate
-
-**Goal.** Structured root-cause analysis for a failed test, regression, or unexpected behavior. Produces a written report so the team (and future-you) can retrace the steps.
-
-Shuri drives. Hawkeye on call for test-specific analysis. Wizer is on call for cross-cutting impact.
-
-## When to run
-
-- A test fails and the cause is not obvious from the diff.
-- A regression appears in production or CI.
-- A user reports a bug with unclear repro steps.
-- An incident triggers post-mortem.
-
-## When NOT to run
-
-- The cause is obvious from the diff → use `wize-quick-dev` to fix directly.
-- A new feature is needed (use `wize-create-story`).
-- A security finding is suspected (escalate immediately; do not investigate solo).
-
-## Inputs
-
-- The failing test, error log, or user report.
-- The commit range since the last known-good state.
-- The relevant story file (if any).
-- A free-form description of the symptoms.
-
-## Output
-
-- `.wize/implementation/investigations/{YYYY-MM-DD}-{short-slug}.md` — a written report.
-
-## Steps
-
-### 1. Frame
-
-One paragraph: what broke, when it was first noticed, who reported it, and how serious. If you cannot write this in 3 sentences, the report is too broad.
-
-### 2. Reproduce
-
-Step-by-step: how to reproduce locally. Include environment (OS, Node version, branch), commands, expected vs. actual output. If unreproducible, mark "not reproducible after N attempts" and stop.
-
-### 3. Hypothesize
-
-List 3 root causes, ranked by likelihood. For each:
-- What would explain the symptoms.
-- A 1-line test to confirm or refute.
-- Confidence: low / medium / high.
-
-### 4. Verify
-
-For each hypothesis, run the 1-line test. Record: confirmed / refuted / inconclusive. If all refuted, return to step 3 and re-rank.
-
-### 5. Conclude
-
-Pick the surviving root cause. State:
-- **Root cause:** {description}.
-- **Fix path:** {one paragraph: what to change and why}.
-- **Effort:** S / M / L.
-- **Risk of fix:** low / medium / high.
-- **Recommended next step:** open a quick-dev, open a story, or escalate.
-
-### 6. Hand off
-
-Notify the next workflow:
-- S / low risk → `/wize-quick-dev` (Shuri fixes directly).
-- M+ or higher risk → `/wize-create-story` (new story for the fix).
-- Escalation → `/wize-correct-course` (involve PM + Wizer).
-
-## Output template
-
-```markdown
----
-date: 2026-06-16
-author: Shuri
-severity: high
-related_story: E04-S02
-related_test: test/document-project-classify.test.js
-status: concluded
----
-
-# Investigation — {short-slug}
-
-## Frame
-{one paragraph}
-
-## Reproduce
-1. ...
-2. ...
-**Expected:** {x}
-**Actual:** {y}
-
-## Hypotheses
-1. **{hypothesis}** — Confidence: high. Test: {1-liner}. Result: confirmed.
-2. ...
-
-## Conclude
-- **Root cause:** {description}
-- **Fix path:** {one paragraph}
-- **Effort:** M
-- **Risk of fix:** low
-- **Next:** /wize-create-story (E04-S05)
-```
-
-## Anti-patterns Shuri rejects
-
-- Skipping the hypothesis ranking. (Ranking forces you to consider alternatives.)
-- Stopping at "I think it's X" without the verification test. (Confirmation bias.)
-- Mixing the investigation with the fix. (Investigate, then propose; do not edit code yet.)
-- One-paragraph reports. (If it's a real investigation, it's at least 5 sections.)
-- Sharing the report only in chat. (Always write to disk for archival.)
-
-## Hand-off
-
-> "Investigation concluded. Root cause: {summary}. Next: `/wize-create-story` (M+ fix) or `/wize-quick-dev` (S fix)."

package/src/method-skills/4-implementation/wize-release/workflow.md

@@ -1,162 +0,0 @@
----
-code: wize-release
-description: "Use quando todas as stories do sprint estiverem gated e você precisar gerar release: bump de versão, changelog e tag git."
-name: Release
-phase: 4-implementation
-owner: wize-agent-dev   # Shuri + Maria Hill
-status: ready
----
-
-# Release
-
-**Goal.** Bump de versão, changelog a partir das stories gated e tag git. O release é o passo entre "todas as stories passaram no gate" e a retrospectiva.
-
-Shuri executa. Maria Hill confirma o escopo (quais epics entram).
-
-## Pré-requisitos
-
-Antes de iniciar, verificar:
-
-1. **Sprint ativo** — `sprint-status.yaml` deve ter `development_status` com stories.
-2. **Todas as stories gated** — cada story no sprint ativo deve estar `done` no `sprint-status.yaml`. Stories com gate `FAIL` bloqueiam o release. Stories com `CONCERNS` precisam de waiver documentado.
-3. **Git limpo** — `git status --porcelain` deve estar vazio (ou conter apenas arquivos não rastreados que não fazem parte do release).
-4. **Branch main** — releases saem da `main`. Se estiver em feature branch, abortar e orientar merge via PR.
-
-Se qualquer pré-requisito falhar, reportar o bloqueio e parar. Não fazer release parcial.
-
-## Inputs
-
-- `.wize/implementation/sprint-status.yaml` — stories concluídas
-- `.wize/solutioning/stories/{epic}/*.md` — detalhes das stories
-- `package.json` — versão atual
-- `CHANGELOG.md` — changelog existente (se houver)
-- `git tag --list 'v*'` — tags existentes
-
-## Outputs
-
-- `package.json` com versão atualizada
-- `CHANGELOG.md` atualizado com a nova versão
-- Tag git `v{semver}`
-- `sprint-status.yaml` atualizado (sprint marcado como concluído)
-- Resumo do release no terminal
-
-## Steps
-
-### 1. Verificar pré-requisitos
-
-```bash
-git status --porcelain  # deve estar vazio
-git branch --show-current  # deve ser main
-```
-
-Ler `sprint-status.yaml` e validar que todas as stories do sprint ativo estão `done`. Se houver stories `backlog`, `ready-for-dev`, `in-progress` ou `review`, listar cada uma e abortar.
-
-### 2. Coletar stories concluídas
-
-Varrer `development_status` no `sprint-status.yaml`. Para cada story com status `done`:
-
-1. Localizar o arquivo da story em `.wize/solutioning/stories/{epic}/{story}.md`
-2. Extrair do frontmatter: `story_id`, `epic`, `status`
-3. Extrair do corpo: título (linha `# Story:`), acceptance criteria
-
-Agrupar por epic. Se o epic tiver `epic_id` no `sprint-status.yaml`, usar o nome do arquivo do epic em `.wize/solutioning/epics/` para obter o título legível.
-
-### 3. Determinar o bump de versão
-
-Ler a versão atual de `package.json`:
-
-```
-Versão atual: 0.11.0
-Qual o bump?
-  1. patch (0.11.1) — correções, hotfix, docs
-  2. minor (0.12.0) — novas features compatíveis
-  3. major (1.0.0) — breaking changes
-```
-
-Em modo interativo, perguntar ao usuário. Em modo não-interativo, usar o primeiro argumento (`patch`, `minor` ou `major`). Se nenhum argumento for passado, default `patch`.
-
-Calcular a nova versão com `semver.inc(current, bump)` — usar Node built-in (regex parse + increment, sem dependência externa).
-
-### 4. Gerar changelog
-
-Delegar a geração do changelog ao `wize-changelog`:
-
-1. Invocar o fluxo do `wize-changelog` com a nova versão e a lista de stories coletadas no passo 2.
-2. O changelog é gerado no formato Keep a Changelog e pré-pendido ao `CHANGELOG.md`.
-
-Se `CHANGELOG.md` não existir, criar com o cabeçalho padrão.
-
-### 5. Bump de versão
-
-Atualizar o campo `version` em `package.json` com a nova versão. Preservar a formatação existente (indentação, aspas duplas).
-
-### 6. Commit e tag
-
-```bash
-git add package.json CHANGELOG.md
-git commit -m "chore: release v{version}"
-git tag v{version} -m "Release v{version}"
-```
-
-A mensagem de commit deve listar os epics incluídos no release.
-
-### 7. Atualizar sprint-status.yaml
-
-Adicionar ao `sprint-status.yaml`:
-
-```yaml
-release:
-  version: "{version}"
-  date: "{YYYY-MM-DD}"
-  sprint: "{active_cycle}"
-  stories_released: {count}
-```
-
-Marcar o sprint como concluído e adicionar entrada de retrospectiva pendente.
-
-### 8. Resumo
-
-Emitir no terminal:
-
-```
-✓ Release v{version} criado
-
-Epics incluídos:
-  - {epic_name} ({story_count} stories)
-
-Changelog: CHANGELOG.md
-Tag: v{version}
-Commit: {commit_hash}
-
-Próximos passos:
-  - git push origin main --tags
-  - /wize-retrospective
-```
-
-**Não executar `git push` automaticamente.** O push é sempre manual — o desenvolvedor revisa antes de publicar.
-
-## Bump semver (built-in, zero-dep)
-
-```js
-function bumpVersion(current, type) {
-  const [major, minor, patch] = current.split('.').map(Number);
-  switch (type) {
-    case 'major': return `${major + 1}.0.0`;
-    case 'minor': return `${major}.${minor + 1}.0`;
-    case 'patch': return `${major}.${minor}.${patch + 1}`;
-    default: throw new Error(`Tipo de bump inválido: ${type}. Use patch, minor ou major.`);
-  }
-}
-```
-
-## Anti-patterns
-
-- Fazer release com stories não gated — o gate existe para proteger a main.
-- Fazer release de feature branch — releases saem da main.
-- Push automático — o desenvolvedor revisa antes de publicar.
-- Pular o changelog — "depois eu escrevo" = nunca escreve.
-- Bump manual de versão — usar o bump semver para evitar off-by-one.
-
-## Hand-off
-
-> Release v{version} criado. Changelog atualizado, tag aplicada. Execute `git push origin main --tags` quando revisar. Depois: `/wize-retrospective`.