wize-dev-kit 0.14.0 → 0.16.0

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

@@ -1,201 +1,33 @@
 ---
-
 code: wize-dev-story
-description: "Use quando uma story estiver pronta para implementação e precisar ser desenvolvida com TDD e commits rastreáveis."
 name: Dev Story
 phase: 4-implementation
 owner: wize-agent-dev   # Shuri
-status: ready
+status: stub
 ---
 
 # Dev Story
 
-**Goal.** Implement one story under TDD discipline. Tests first; minimum code to pass; refactor with green. Each commit cites an AC ID. The PR ends in a clean gate, not a "looks good to me."
-
-Shuri drives. Hawkeye observes (test design is binding). Tony stays available for architectural questions.
-
-## Operating contract
-
-I work inside a repo with WDK installed: `.wize/`, `AGENTS.md`, and the `wize-*` skills are my instructions and memory, not background reading. This section is the execution slice of the story's **mission contract** (see `/wize mission` or `/wize-help mission`).
-
-- **Inspect before editing.** Read the story, its sources of truth, and the touched code first.
-- **Reuse ladder before new code** (see `wize-agent-dev` persona): needs to exist → already here → stdlib → framework feature → installed dep → one-liner → only then new code.
-- **Test-first, unconditionally.** Red before green, per the loop below — this is the strict-TDD workflow; the "when applicable" latitude lives in `wize-quick-dev`, not here. Smallest sufficient change; follow existing conventions.
-- **Run real commands.** No success claim without evidence — a passing run, not "should pass."
-- **Never stop at planning.** Planning is a step, not a deliverable.
+**Goal.** Implement one story under TDD discipline.
 
 ## Inputs
-
-- `.wize/solutioning/stories/{epic}/{story}.md`
+- `.wize/solutioning/stories/{epic}/{story-id}.md`
 - `.wize/solutioning/architecture.md`
-- `.wize/solutioning/design-system/` (use existing components)
-- `.wize/implementation/tea/{epic}/{story}/design.md` (the test contract)
+- `.wize/implementation/tea/{epic}/{story-id}/design.md` (Hawkeye must have produced this)
 
 ## Outputs
-
-- Code + tests in the target repo.
-- Commit messages reference AC IDs.
-- Story file updated to `status: ready-for-review`.
-
-## The loop (TDD, story-scoped)
-
-### 1. Read
-
-Story ACs, out-of-scope, notes, `tea-design.md`. Confirm the test split. If the design doesn't match the story (mismatch on test count, mock, environment), ping Hawkeye **before** writing code.
-
-### 2. Slice the story into micro-cycles
-
-Each cycle is one AC (or part of one) and produces a green test + small code change. Don't try to ship the whole story in one commit.
-
-### 3. Red
-
-Write the failing test first. Match the assertion shape in `design.md`. Don't write code yet.
-
-```ts
-// red — first run, fails
-test('valid email returns ok', () => {
-  expect(validateInviteEmail('a@b.co')).toEqual({ ok: true });
-});
-```
-
-### 4. Green
-
-Before writing anything new, run Shuri's reuse ladder (see `wize-agent-dev` persona): does this need to exist → already in the codebase → stdlib → native/framework feature → installed dependency → one-liner → only then new code. Write the **minimum** code that turns the test green. No anticipated branches; no "just-in-case" handling.
-
-```ts
-// green — minimum to pass
-export const validateInviteEmail = (s: string) => ({ ok: /@/.test(s) });
-```
-
-### 5. Refactor
-
-Now harden, with the test as safety net.
-
-```ts
-// refactor — same green tests, real logic
-import { z } from 'zod';
-const schema = z.string().email();
-export const validateInviteEmail = (s: string) =>
-  schema.safeParse(s).success ? { ok: true } : { ok: false, code: 'invalid_format', field: 'email' };
-```
-
-### 6. Commit
-
-Conventional commits, AC IDs referenced.
-
-```
-feat(invite): validate email per AC-02-1 / AC-02-2
-- add validateInviteEmail with zod
-- add 4 unit tests covering valid + invalid rules
-```
-
-### 7. Repeat
-
-Until every AC has at least one test + minimum code that makes it pass.
-
-### 7.5. Loop verification (auto-check)
-
-Before declaring the loop done, run these checks:
-
-| Check | How | Fail → |
-|---|---|---|
-| **Evidence of iteration** | `git log --oneline` shows ≥2 commits with AC IDs (skip if story has only 1 AC) | Return to step 2 |
-| **AC-to-test mapping** | Every AC in the story file has a corresponding test case name | Return to step 3 (Red) |
-| **All AC tests green** | `npx vitest run --reporter=verbose` (or equivalent) — grep output for each AC's test name | Return to step 4 (Green) |
-
-**Max-cycles guard.** If the same AC cycles through Red→Green→Refactor 3+ times without staying green, stop and escalate to Wizer: the test design may be wrong, the AC may be mis-sized, or the approach may need Tony.
-
-### 8. Knowledge update (inline, ~60s)
-
-Before opening the PR, ask: **did this story touch any of the 5 baseline axes** documented in `.wize/knowledge/document-project/`?
-
-| Axis | Touched when… | File to update |
-|---|---|---|
-| **Architecture** | new component, new sequence, changed data flow | `architecture-snapshot.md` |
-| **Conventions** | new naming/folder/test pattern published as public contract (incl. `testid`) | `conventions.md` |
-| **Risk-spots** | introduced a complexity hot spot OR resolved one | `risk-spots.md` |
-| **Dependencies** | added / removed / upgraded a runtime dep | `dependencies.md` |
-| **Overview** | new user-visible feature a new dev should know about | `overview.md` |
-
-If yes for any axis: open the file and add **1–3 lines** under a new dated bullet — in the same PR.
-
-```markdown
-## 2026-06-12 — E01-S03
-- Conventions: `data-testid="invite-*"` published as public contract; Hawkeye E2E depends on these.
-- Risk: R-1 (mailer) mitigation now confirmed (integration test covers retry policy).
-```
-
-If no axis was touched, you skip this step entirely — quick-dev-style changes don't need it. Hawkeye will check whether the call was correct in `tea-review`. A story that touched an axis but skipped the update gets a `KN-NN` finding in the gate (recommendation `CONCERNS` advisory, or `FAIL` enforcing).
-
-This is how the brownfield baseline stays alive instead of going stale 6 months in.
-
-### 9. Pre-PR self-check
-
-- All Hawkeye-declared tests exist + pass — **AC → test mapping complete**, every AC traced to a named passing test.
-- Required checks run: unit + integration + e2e (as the test contract declares), lint, format, type-check, build — and security when the story touches auth/payments/boundaries. If a command couldn't run, say **exactly which and why** — don't silently drop it.
-- No `test.skip` / `.only` left.
-- Authz enforced at every server boundary the story adds.
-- Loading / empty / error states rendered and asserted.
-- `data-testid` matches story's "notes for Hawkeye".
-- Story file frontmatter → `status: ready-for-review`.
-- Self-walk the screen (web) or smoke a tab on simulator (app).
-
-### 10. Open PR
-
-PR description includes:
-- Story link.
-- AC list with the test names that cover them.
-- Screenshots / recordings of happy + failure paths.
-- Knowledge update line (`Touched axis: <none|architecture|conventions|risk-spots|dependencies|overview>`).
-- TEA expected next: design → trace → review → gate.
-
-### 11. Address gate findings
-
-If `tea-review` or `tea-gate` flags issues, fix them in the same PR or open a follow-up if the story has shipped a separate value-bearing slice.
-
-**Loop-back protocol:**
-1. Read each finding's `severity` and `blocking` flag.
-2. For each `blocking: true` finding → return to step 3 (Red) for the affected AC.
-3. For each `blocking: false` finding → log in story `notes` and fix in same PR before re-submitting to gate.
-4. **Max-retry guard:** if the same story cycles through gate → fix → gate 3+ times, stop and escalate to Wizer. The story may be mis-sized, the test design may be wrong, or the ACs may need renegotiation with Hill.
-
-## Security + perf during implementation
-
-Shuri thinks both at write time, not at review time:
-
-- Auth context on every server entry point — confirm via Tony's middleware pattern.
-- Tokens never logged.
-- Inputs validated at the boundary; trusted by the time they reach domain.
-- Network calls in handlers wrapped with timeout + retry policy from architecture.
-- Don't `await` in a loop without batching.
-- Don't ship dead code (`isFooEnabled = true` always).
+- Code + tests in the target repo
+- Commit messages reference AC IDs
+- Story file updated to `status: ready-for-review`
+
+## Steps (TDD loop)
+1. **Read.** Story ACs and Hawkeye's design.
+2. **Red.** Write the failing test first.
+3. **Green.** Minimum code to pass.
+4. **Refactor.** Clean — only with green tests.
+5. **Repeat** until every AC has at least one test.
+6. **Self-check.** Security, perf, dead code, naming.
+7. **Hand-off.** Ping Hawkeye for trace + review.
 
 ## Quick-dev exception
-
-If the work is small / well-scoped and Wizer invoked `wize-quick-dev` instead of this workflow, the design step is replaced by smoke-test-only commitment and the gate is a single one-line entry in `quick-dev-log.md`.
-
-## Anti-patterns Shuri rejects in her own work
-
-- Writing code first and tests "after the bug fix" — that's not TDD; that's regression-tests.
-- Commits that don't cite an AC.
-- "Refactor while green" turning into "rewrite while green."
-- Bundling cross-cutting refactors into the story PR. Split.
-- Editing tests so they pass instead of editing code so tests pass.
-
-## Final report
-
-When the story is done, report to the thread in this shape — decisions, evidence, results, blockers only; no extended private reasoning:
-
-1. **Route used** — full lifecycle (dev-story).
-2. **Solution summary** — what changed and why, in a few lines.
-3. **Files changed.**
-4. **AC → test mapping** — each AC and the passing test that covers it.
-5. **Commands run + results** — the real checks and their outcomes; name any that couldn't run and why.
-6. **`.wize/` artifacts updated** — story status, TEA artifacts, knowledge axes.
-7. **Relevant decisions** — including any ADR if architectural.
-8. **Residual risks / limitations / skipped items** — including recommended extras logged separately (no silent scope creep).
-9. **Single recommended next action** — usually the TEA gate.
-
-## Hand-off
-
-> Story E01-S03 implemented. All ACs covered by tests; CI green. PR opened (#412). Hawkeye, ready for trace + review. Notes section of the story has the testid map you'll use.
+If invoked via `wize-quick-dev`, the design step is replaced by smoke-test-only commitment.

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

@@ -1,151 +1,33 @@
 ---
-
 code: wize-quick-dev
-description: "Use quando a demanda for pequena e bem delimitada (bug fix, copy edit, refactor) e não justificar o ciclo completo."
 name: Quick Dev (lifecycle shortcut)
 phase: 4-implementation
 owner: wize-agent-dev   # Shuri
-status: ready
+status: stub
 ---
 
 # Quick Dev
 
-**Goal.** When the task is small and well-scoped (bug fix, copy edit, small refactor, dep bump, brownfield maintenance), skip Phase 1–3 and execute with light TEA. Save the full lifecycle for new value.
-
-Wizer authorizes the shortcut (via routing). Shuri runs it. Hawkeye does smoke-only.
-
-## Operating contract (light)
-
-Still a **mission contract**, just a small one: `.wize/` + `AGENTS.md` + skills are the instructions. Inspect before editing, reuse ladder before new code, smallest sufficient change, test-first when the change has a testable surface, run the real smoke + checks, no success claim without evidence. If it grows past ~1h or touches a new feature/architecture/UX/security surface, stop and re-route to Full Lifecycle — don't force it through here.
-
-## When to use (yes)
-
-- Bug fix with a clear root cause.
-- Copy or content edit.
-- Small refactor with no behavior change.
-- Dependency bump (security or minor).
-- Brownfield maintenance: rename, structural cleanup, dead-code removal.
-- Hotfix during incident response (post-mortem after).
-
-## When NOT to use (no)
-
-- New feature, even small.
-- Cross-cutting change touching architecture.
-- Changes where ACs need to be agreed.
-- Anything that should be a story.
-- Anything that touches security/auth/payments without senior review.
-
-## Decision tree
-
-```
-Question                              Yes              No
-Is there an AC to write?              → full lifecycle  → next
-Does it touch architecture?           → full lifecycle  → next
-Does it need UX input?                → full lifecycle  → next
-Could it surprise a user?             → full lifecycle  → next
-Is it ≤ 1 hour to a careful dev?      → quick-dev       → full lifecycle
-```
-
-## Inputs
+**Goal.** When the task is small and well-scoped (bug fix, copy edit, small refactor), skip the full lifecycle.
 
-- Issue / Slack message / PR comment describing the problem.
-- Repo state.
-- `.wize/config/tea.toml` (smoke-only policy when `policy = "advisory"`).
+## When to use
+- Bug fix with clear root cause
+- Copy or content edit
+- Small refactor with no behavior change
+- Dependency bump
+- Brownfield maintenance
 
-## Output
-
-- Code change (single PR).
-- Single-line entry appended to `.wize/implementation/quick-dev-log.md`.
-- Conventional commit.
+## When NOT to use
+- New feature
+- Cross-cutting change touching architecture
+- Anything where ACs need to be agreed
 
 ## Steps
-
-### 1. Frame in one paragraph
-
-What changes, why, and what could break. If the paragraph is hard to write, you're not in quick-dev territory.
-
-### 2. Implement
-
-- TDD when reasonable; smoke-test-and-fix when the cost of TDD is greater than the value.
-- Run Shuri's reuse ladder (see `wize-agent-dev` persona) before writing anything new: does this need to exist → already in the codebase → stdlib → native/framework feature → installed dependency → one-liner → only then new code. Don't introduce new abstractions.
-
-### 3. Hawkeye lite
-
-- Smoke test: imports load, the changed flow doesn't break.
-- Lint + format + type-check clean.
-- No `tea-design / trace / review / nfr` written.
-- Single one-line gate entry instead of full `gate.md`.
-
-### 4. Log
-
-Append one line to `.wize/implementation/quick-dev-log.md`:
-
-```
-2026-06-11 | shuri | dep-bump zod 3.22→3.23 | smoke PASS | PR #418
-2026-06-11 | shuri | fix copy on /signin help link | smoke PASS | PR #419
-2026-06-11 | shuri | rename UserService → AccountService | smoke PASS | PR #420
-```
-
-### 5. Knowledge update (only if applicable)
-
-Most quick-dev changes don't touch the baseline axes (copy edit, small refactor, dep bump in a stable lib). When they do — typically a **dependency bump** or a **rename that breaks a public contract** — add **one line** to the matching `document-project/*.md` file:
-
-```markdown
-## 2026-06-11
-- Dependencies: bump zod 3.22 → 3.23. No API changes; validateInviteEmail unaffected.
-- Conventions: `AccountService` replaces `UserService` (rename); imports updated repo-wide.
-```
-
-Heuristic: *"would a new dev hitting `document-project/*.md` next week be misled if I don't add this?"* Yes → write. No → skip.
-
-### 6. Commit + open PR
-
-Conventional commit. PR description: the paragraph from step 1.
-
-```
-fix(auth): typo in error message for AC-04-2 follow-up
-
-The error shown after rate-limit said "Sloow down" — corrected to "Slow down".
-No behavior change; copy-only.
-```
-
-## Quick-dev log template
-
-```markdown
-# Quick-dev log
-
-| Date | Owner | What | Smoke | PR |
-|---|---|---|---|---|
-| 2026-06-11 | shuri | … | PASS | #N |
-```
-
-## Done report (compact)
-
-Report in four lines — no ceremony:
-
-1. What changed + why.
-2. Files changed.
-3. Checks run + results (smoke, lint, format, type-check). Name any that couldn't run and why.
-4. Recommended next action, if any.
+1. **Frame.** One paragraph: what changes and why.
+2. **Implement.** TDD or smoke-test-and-fix, depending on risk.
+3. **Hawkeye lite.** Smoke test + lint only (no design/trace/nfr/review).
+4. **Gate.** Tiny `gate.md` (PASS or CONCERNS) appended to a rolling `.wize/implementation/quick-dev-log.md`.
+5. **Commit.** Conventional commit referencing the change.
 
 ## Disabling
-
-To force every change through the full lifecycle (for very high-stakes products), set in `.wize/config/project.toml`:
-
-```toml
-[install]
-quick_dev_enabled = false
-```
-
-Wizer respects this; quick-dev becomes unavailable; every change must go through Pepper → … → Hawkeye gate.
-
-## Anti-patterns Shuri rejects in herself
-
-- Reaching for quick-dev to skip writing an AC because she doesn't want to argue with Hill.
-- Quick-dev that touches security/auth/payments.
-- A "small refactor" that ends up changing behavior.
-- Skipping the log entry.
-
-## Hand-off
-
-> `dep-bump zod 3.23` is in. PR #418, smoke PASS. Logged. No further TEA artifacts; moving on.
+Set `quick_dev_enabled = false` in `.wize/config/project.toml` to force full lifecycle for everything.

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

@@ -1,140 +1,36 @@
 ---
-
 code: wize-retrospective
-description: "Use quando o sprint terminar e precisar de retrospectiva facilitada com todo o time."
 name: Retrospective
 phase: 4-implementation
 owner: wize-orchestrator   # Wizer facilitates; whole team contributes
-status: ready
+status: stub
 ---
 
 # Retrospective
 
-**Goal.** Capture what worked, what didn't, what surprised, and **one concrete change for next sprint**. A retro that ends in a vibe is a retro that didn't ship a change.
-
-Wizer facilitates. Hill enforces output discipline. Everyone (including Pepper, Mantis, Fury) contributes.
-
-## When to run
-
-- End of every sprint (cadence).
-- After any incident (separate; pulls from incident timeline).
-- At major milestones (epic close, release, year-end).
+**Goal.** Capture what worked, what didn't, and what we change next sprint.
 
 ## Inputs
-
 - `.wize/implementation/sprint-status.md` (current sprint)
 - All `gate.md` files from current sprint
-- `tea/nfr/{epic}.md` if an epic closed this sprint
-- Quick-dev log
-
-## Output
 
+## Outputs
 - `.wize/implementation/retrospective/{YYYY-MM-DD}.md`
 
-## Format (60 minutes, fixed)
-
-| Minutes | Section |
-|---|---|
-| 0–5 | Frame: Wizer reads the sprint stats (capacity, shipped, slipped, gates). |
-| 5–15 | **Worked** — what we want to repeat. |
-| 15–25 | **Didn't work** — what we want to change. |
-| 25–35 | **Surprised us** — externalities, signals, anything not on plan. |
-| 35–45 | Pick **1–3 changes**. Vote with effort/impact dots. |
-| 45–55 | Each change gets an owner + deadline. |
-| 55–60 | Wizer reads back the doc; everyone confirms; close. |
-
-Going over 60 minutes is a sign the retro became therapy. Time-box.
-
-## Steps
-
-### 1. Open with stats
-
-Wizer reads the sprint dashboard from `sprint-status.md`:
-- Stories committed vs shipped (a count, not a velocity metric — we don't estimate).
-- Number of gates: PASS / CONCERNS / FAIL / WAIVED.
-- Blockers and their resolution times.
-- Carry-over count.
-
-Stats anchor the retro in observations, not feelings.
-
-### 2. Worked / didn't / surprised
-
-Each engineer brings 2–3 items per section, written in advance ideally. Time-box discussion: any item that takes > 3 min becomes a follow-up.
-
-### 3. Changes (1–3 max)
-
-A change is:
-- **Specific:** "Pair-program for E04-S02 because R-3 is high" — not "communicate more."
-- **Owned:** a person.
-- **Bounded:** a deadline or a sprint to land it.
-
-If you pick 4+ changes, you'll execute 0. Choose.
-
-### 4. Write the doc
-
-Use the template; close the retro with the doc in front of the team.
-
-### 5. Trigger reads
-
-Wizer notifies Hill (who plugs the changes into next sprint planning), Hawkeye (who may revise risk profile), Fury (when an NFR principle change emerges).
-
-## Output template
+## Template
 
 ```markdown
----
-sprint: 7
-date: 2026-06-25
-facilitator: Wizer
-attendees: [Hill, Tony, Mantis, Pepper, Fury, Hawkeye, Shuri]
----
-
-# Retrospective — Sprint 7
-
-## Sprint snapshot
-- Committed: 4 stories + 1 stretch
-- Shipped: 4 stories
-- Stretch: not pulled
-- Gates: 4 PASS, 1 CONCERNS, 0 FAIL
-- Blockers: 1 (vendor sandbox, resolved Day 5)
-- Carry-over to S8: 0
+# Retrospective — Sprint N
 
 ## Worked
-- Pairing on E03-S02 (auth refresh) — issue caught at integration test instead of in prod.
-- TEA design done at planning for R-3 stories paid off.
-- Mantis' "before/after" recordings in PRs accelerated review.
+- …
 
 ## Didn't work
-- Sprint-status entries went stale mid-sprint (Hill on vacation).
-- E02-S02 was too big for one PR and should have been sliced; it stalled the sprint.
-- Vendor outage with no fallback caught us cold.
+- …
 
 ## Surprised us
-- A11y audit caught 3 issues on a screen Mantis had already signed off on (axe found dynamic-content edge cases).
-- Cost dashboard showed mailer spend doubled — outbox retry was too aggressive.
-
-## Changes for Sprint 8
-
-1. **Sprint-status delegation rotation** — when Hill is OOO, Wizer takes over. *Owner: Wizer. By: Sprint 8 Day 1.*
-2. **Slice-check every story at planning** — any story that can't be described as a single PR gets split before it's pulled. *Owner: Tony. By: Sprint 8 planning.*
-3. **Vendor fallback drill** — quarterly, simulate top-3 vendor outages. *Owner: Hawkeye + Tony. By: end of Q3.*
-
-## Decisions made
-- Mailer retry policy updated (NFR-01-1).
-- Risk profile revised: R-1 mitigation now confirmed.
+- …
 
-## Notes for next sprint
-- Carry zero stories; everyone starts S8 fresh.
-- Stretch goal in S8: catch up on REV-01 (copy fix from S7).
+## Changes next sprint (owner + due date)
+- [ ] … — owner: …
 ```
-
-## Anti-patterns Wizer rejects (politely)
-
-- **A retro without a change.** Then it was venting.
-- **"We need to communicate better."** Specific or it doesn't count.
-- **Adopting > 3 changes.** None will land.
-- **No owner / no deadline.** Hopes, not plans.
-- **Skipping the retro to "save time."** The next sprint costs more.
-
-## Hand-off
-
-> Retro at `.wize/implementation/retrospective/2026-06-25.md`. 3 changes; owners assigned. Sprint 8 planning anchors on them. Hawkeye, please update `risk-profile.md` with the R-1 mitigation confirmed.

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

@@ -1,91 +1,24 @@
 ---
-
 code: wize-sprint-planning
-description: "Use quando um novo sprint começar e precisar planejar as stories, prioridades e capacidade do time."
 name: Sprint Planning
 phase: 4-implementation
 owner: wize-agent-pm   # Maria Hill
-status: ready
+status: stub
 ---
 
 # Sprint Planning
 
-**Goal.** Pick what enters this sprint. Capacity-honest, priority-honest, risk-honest.
-
-Maria Hill chairs. Tony advises on slicing. Hawkeye flags risk. Shuri commits to the load.
-
-> **No estimates.** Plan by story count and priority, never by velocity, points, or person-day math. Estimates only burn time and tokens. Pull what fits, keep a buffer, and let shipped-vs-committed counts (not a velocity number) tell you next time.
+**Goal.** Pick what enters this sprint. Capacity-honest, priority-honest.
 
 ## Inputs
+- Story backlog from `.wize/solutioning/stories/`
+- Velocity history (if exists) from `.wize/implementation/sprint-status.md`
+- Hawkeye risk profile (`risk-profile.md`)
 
-- Story backlog: `.wize/solutioning/stories/`
-- Previous sprint state: `.wize/implementation/sprint-status.yaml`
-- `.wize/implementation/tea/risk-profile.md`
-- Team availability for the next interval.
-
-## Output
-
-- Updated `.wize/implementation/sprint-status.yaml`.
-- Story files updated with `priority: 1` for chosen stories.
-
-## Steps
-
-1. **Look back** — what shipped, what slipped, what surprised (counts, not velocity).
-2. **Gauge availability** — who's around this interval and who's out. No person-day math.
-3. **Pull stories** — continuation first, then priority, then risk.
-4. **Leave slack** for unknowns — pull fewer stories than feel possible, not a padded number.
-5. **Walk the gate plan** — design/trace/review/gate per story.
-6. **Commit** — verbal + written into YAML.
-
-## Status state machine
-
-- Epic: `backlog` → `in-progress` → `done`
-- Story: `backlog` → `ready-for-dev` → `in-progress` → `review` → `done`
-- Retrospective: `optional` ↔ `done`
-
-## Sprint block template
-
-```yaml
-# generated: YYYY-MM-DD
-# last_updated: YYYY-MM-DD
-# project: {project_name}
-# project_key: {project_key}
-# tracking_system: file-system
-# story_location: .wize/solutioning/stories
-
-generated: YYYY-MM-DD
-last_updated: YYYY-MM-DD
-project: {project_name}
-project_key: {project_key}
-tracking_system: file-system
-story_location: .wize/solutioning/stories
-
-development_status:
-  epic-1: backlog
-  1-1-story-one: backlog
-  1-2-story-two: backlog
-  epic-1-retrospective: optional
-```
-
-## Anti-patterns
-
-- Estimating — velocity, points, or person-days. Just don't.
-- Over-committing because "it looks like it fits."
-- Stories without owners.
-- Stretch goals that are really plan.
-- Pulling blocked dependencies.
-- Zero slack.
-
-## Hand-off
+## Outputs
+- Sprint entry appended to `.wize/implementation/sprint-status.md`
 
-> Sprint committed at `.wize/implementation/sprint-status.yaml`. Stories in `ready-for-dev` are now eligible for the dev loop.
->
-> **Recommended next loop:**
->
-> ```
-> /loop /wize-dev-story
-> ```
->
-> `/loop /wize-dev-story` drives one story at a time: TDD red-green-refactor, AC IDs in commits, `tea-design.md` contract, knowledge update on the 5 baseline axes, and a clean gate at the end. `/loop` keeps it going across the sprint's `ready-for-dev` queue until the user pauses.
->
-> Next: `/wize-sprint-status` (Maria Hill) to track progress.
+## Rules
+- High-risk stories get TEA design done first or are deferred.
+- Velocity = the smaller of "what we shipped last sprint" and "what we estimate we can ship this sprint."
+- Stretch goals are explicit, not silent.