wize-dev-kit 0.1.4 → 0.2.0

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

@@ -3,31 +3,122 @@ code: wize-quick-dev
 name: Quick Dev (lifecycle shortcut)
 phase: 4-implementation
 owner: wize-agent-dev   # Shuri
-status: stub
+status: ready
 ---
 
 # Quick Dev
 
-**Goal.** When the task is small and well-scoped (bug fix, copy edit, small refactor), skip the full lifecycle.
+**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.
 
-## When to use
-- Bug fix with clear root cause
-- Copy or content edit
-- Small refactor with no behavior change
-- Dependency bump
-- Brownfield maintenance
+Wizer authorizes the shortcut (via routing). Shuri runs it. Hawkeye does smoke-only.
 
-## When NOT to use
-- New feature
-- Cross-cutting change touching architecture
-- Anything where ACs need to be agreed
+## 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
+
+- Issue / Slack message / PR comment describing the problem.
+- Repo state.
+- `.wize/config/tea.toml` (smoke-only policy when `policy = "advisory"`).
+
+## Output
+
+- Code change (single PR).
+- Single-line entry appended to `.wize/implementation/quick-dev-log.md`.
+- Conventional commit.
 
 ## Steps
-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.
+
+### 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.
+- Reuse existing components. 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. 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 |
+```
 
 ## Disabling
-Set `quick_dev_enabled = false` in `.wize/config/project.toml` to force full lifecycle for everything.
+
+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.

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

@@ -3,34 +3,136 @@ code: wize-retrospective
 name: Retrospective
 phase: 4-implementation
 owner: wize-orchestrator   # Wizer facilitates; whole team contributes
-status: stub
+status: ready
 ---
 
 # Retrospective
 
-**Goal.** Capture what worked, what didn't, and what we change next sprint.
+**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).
 
 ## 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`
 
-## Template
+## 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`:
+- Velocity vs commitment.
+- 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
 
 ```markdown
-# Retrospective — Sprint N
+---
+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
 
 ## 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 on Days 7–8 (Hill on vacation).
+- E02-S02 estimated M, actually L; we over-committed.
+- Vendor outage with no fallback caught us cold for 4h.
 
 ## 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. **L estimates require justification** — any L gets one paragraph "why L not M" in the story file. *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.
 
-## Changes next sprint (owner + due date)
-- [ ] … — owner: …
+## Notes for next sprint
+- Carry zero stories; everyone starts S8 fresh.
+- Stretch goal in S8: catch up on REV-01 (copy fix from S7).
 ```
+
+## 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

@@ -3,22 +3,97 @@ code: wize-sprint-planning
 name: Sprint Planning
 phase: 4-implementation
 owner: wize-agent-pm   # Maria Hill
-status: stub
+status: ready
 ---
 
 # Sprint Planning
 
-**Goal.** Pick what enters this sprint. Capacity-honest, priority-honest.
+**Goal.** Pick what enters this sprint. Capacity-honest, priority-honest, risk-honest. The sprint is a commitment about a small slice of the future, not a wish list.
+
+Maria Hill chairs. Tony advises on slicing. Hawkeye flags risk on stories. Shuri commits to the load.
 
 ## Inputs
-- Story backlog from `.wize/solutioning/stories/`
-- Velocity history (if exists) from `.wize/implementation/sprint-status.md`
-- Hawkeye risk profile (`risk-profile.md`)
 
-## Outputs
-- Sprint entry appended to `.wize/implementation/sprint-status.md`
+- Story backlog: `.wize/solutioning/stories/`
+- Velocity history: `.wize/implementation/sprint-status.md` (previous sprints) — when present.
+- `.wize/implementation/tea/risk-profile.md`
+- Open `tea-gate` outcomes from last sprint.
+- Team availability for the next interval (vacations, on-call rotation, planned meetings).
+
+## Output
+
+- New sprint block appended to `.wize/implementation/sprint-status.md`.
+- Story files updated `priority: 1` for chosen stories.
 
 ## 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.
+
+1. **Capacity = min(history velocity, declared availability).** Not the average of optimistic estimates.
+2. **High-risk stories** (linked to `R-x` HIGH in risk profile) get TEA design done in the planning meeting, not at story start.
+3. **Stretch goals** are explicit, named, not silent. If a stretch ships, great. If not, the sprint isn't a failure.
+4. **Don't carry over without reason.** A carried-over story gets a one-line "why" in the sprint log.
+
+## Steps
+
+### 1. Look back (3 min)
+
+Last sprint: what shipped, what slipped, what surprised. Don't relitigate; observe.
+
+### 2. Refresh capacity
+
+- Person-days available this sprint = sum(working days) × (1 - meetings load).
+- Subtract on-call burden, oncall handoff time, planned reviews.
+
+### 3. Pull stories (in priority order)
+
+Default selection algorithm:
+- Always pull continuation stories (in-flight from last sprint) first.
+- Then highest-priority stories that fit the capacity.
+- Then risk-driven: high-risk stories (R-HIGH) preferred over more low-risk ones when capacity is tight.
+
+For each pulled story, confirm INVEST still holds; re-slice if needed.
+
+### 4. Reserve buffer
+
+10–15% buffer for unknowns (bug fixes, support escalations). Don't fill the sprint to 100% — you'll always pay.
+
+### 5. Walk the gate plan
+
+For each story pulled, what's the TEA gate cadence? Most stories: design at start, trace + review + gate at end. High-risk: include NFR re-check at epic close.
+
+### 6. Commit (verbal + written)
+
+Each engineer reads back the stories they're owning. Hill writes them into the sprint block. Sprint starts.
+
+## Sprint block template (appended to `sprint-status.md`)
+
+```markdown
+## Sprint 7 — 2026-06-12 → 2026-06-25
+
+**Capacity:** 24 person-days (3 engineers × 10 days × 0.8 utilization)
+**Carry-over:** E01-S05 (90% done; Shuri); E03-S01 (TEA review pending)
+**Pulled:**
+- E01-S06 — M — owner: Shuri — gate cadence: design+gate
+- E02-S02 — L — owner: Shuri — gate cadence: design+trace+review+gate (R-3)
+- E03-S02 — M — owner: Aaliyah — gate cadence: design+trace+review+gate (R-1)
+- E04-S01 — S — owner: Shuri — gate cadence: smoke (quick-dev pattern)
+- E02-S03 — S — stretch
+
+**Out (deferred to Sprint 8):**
+- E03-S03 — reason: depends on E03-S02 ADR
+- E05-S01 — reason: out of NFR-cost budget; revisit
+
+**Risks flagged:**
+- E02-S02 — auth refresh story; high-risk; TEA design done at planning.
+```
+
+## Anti-patterns Hill rejects
+
+- **"Optimistic" velocity that ignores history.** Use observed velocity.
+- **Stories pulled without owners.** Don't aspire; commit.
+- **Stretch goals so big they're really plan.** Stretch = optional, not "we hope we can."
+- **Pulling a story when its dependency hasn't shipped.** It will sit blocked.
+- **No buffer.** Real sprints have surprises.
+
+## Hand-off
+
+> Sprint 7 committed at `.wize/implementation/sprint-status.md`. Shuri owns most; Aaliyah picks up E03-S02. Hawkeye, NFR gate due on E03 at sprint end. Wizer, retro on the 25th.

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

@@ -3,23 +3,108 @@ code: wize-sprint-status
 name: Sprint Status
 phase: 4-implementation
 owner: wize-agent-pm   # Maria Hill
-status: stub
+status: ready
 ---
 
 # Sprint Status
 
-**Goal.** Daily snapshot of in-flight stories. Blockers up front.
+**Goal.** Keep a snapshot of in-flight work that the team and stakeholders can read in 60 seconds. Sprint status is read by everyone, written by Hill (or delegated to Wizer); the source of truth is the file, not Slack.
 
-## Outputs
-- Updates appended to `.wize/implementation/sprint-status.md`
+Update **daily** during a sprint, or after any state change (story moves, blocker appears, gate fails).
+
+## Inputs
+
+- `.wize/solutioning/stories/` (current statuses)
+- `.wize/implementation/tea/{epic}/{story}/gate.md` (gate outcomes)
+- The team (verbal stand-up or async update)
+
+## Output
+
+- Updated entry in `.wize/implementation/sprint-status.md`.
+
+## Steps
+
+### 1. Per story, name a status
+
+| Status | Meaning |
+|---|---|
+| `pulled` | Committed for this sprint, not started yet |
+| `in-progress` | Engineer actively working it (or paused < 1 day) |
+| `paused` | Started, paused > 1 day, reason listed |
+| `blocked` | Cannot proceed; depends on a named external resolution |
+| `in-review` | PR open; Hawkeye running design → trace → review |
+| `gate-PASS` / `gate-CONCERNS` / `gate-FAIL` | TEA gate outcome |
+| `shipped` | Merged to main + deployed (when applicable) |
+
+### 2. Blockers up front
+
+Blockers always appear in the top section. Each gets:
+- Owner (the person who can unblock it).
+- Specific ask (the action they should take).
+- Deadline.
+
+If a blocker sits longer than 2 days, Hill escalates. Stalled blockers are how sprints fail silently.
+
+### 3. Trend
+
+Daily, write a one-line trend: *"On track."* / *"At risk for E03-S02 due to vendor outage."* / *"Slipping; will defer E04-S01 to next sprint."*
+
+### 4. Capture decisions
+
+If something material was decided during the sprint that affects the plan (story sliced, scope dropped, ADR opened), append a one-line entry.
+
+## File template
 
-## Format
 ```markdown
-## Sprint N — Day D
-- Story E01-S03 — in progress (Shuri). Blocked: no.
-- Story E01-S04 — TEA design — Hawkeye.
-- Story E02-S01 — done (gate PASS).
+# Sprint status
 
-Blockers:
-- (none) | or specific list
+## Sprint 7 — 2026-06-12 → 2026-06-25
+
+### Day 4 (2026-06-15)
+**Trend:** On track.
+
+**Blockers:**
+- (none)
+
+**Stories:**
+- E01-S05 — gate-PASS — shipped (carry-over from S6).
+- E01-S06 — in-progress — Shuri.
+- E02-S02 — in-review — PR #418; Hawkeye doing trace.
+- E03-S02 — in-progress — Aaliyah.
+- E04-S01 — pulled — Shuri starts after E01-S06.
+- E02-S03 (stretch) — pulled — Aaliyah picks up if capacity allows.
+
+**Decisions:**
+- E03-S03 sliced into two stories (E03-S03a, E03-S03b) — ADR-009 incoming.
+
+### Day 5 (2026-06-16)
+**Trend:** At risk on E02-S02 (vendor sandbox down; Hawkeye unblocked at 14:00).
+**Blockers:** Resolved.
+**Stories:** (changes from Day 4)
+- E02-S02 — gate-PASS at 16:30; merged.
+- E01-S06 — in-review — PR #419.
+
+## Sprint 6 — 2026-05-29 → 2026-06-11
+{{archived}}
 ```
+
+## Daily cadence (lean)
+
+A daily standup, when present, is 5 minutes max:
+
+- "What did I ship since last time?"
+- "What am I shipping next?"
+- "Anything blocking me?"
+
+Hill updates `sprint-status.md` immediately after; Wizer reads it before any other agent's session that day.
+
+## Anti-patterns Hill rejects
+
+- "Status: in progress" for 4 days with no further detail. Either it really is, in which case slice progress, or it's stuck.
+- Blockers without an owner or a deadline.
+- Sprint goals that drift silently (added stories without removing others).
+- Stale entries in the file. Update daily or delegate the update.
+
+## Hand-off
+
+> `sprint-status.md` updated. Day 5 trend: at-risk-mitigated. Wizer, if asked about state, the file is the answer. Pepper, brief stays valid; no scope move triggered.

package/src/tea-skills/wize-tea-design/workflow.md

@@ -4,35 +4,126 @@ name: TEA Test Design
 gate: design
 owner: wize-agent-test-architect   # Hawkeye
 when: per-story-start
-status: stub
+status: ready
 ---
 
 # TEA — Test Design
 
-**Goal.** For one story: declare the test split (unit / integration / e2e), required fixtures, mocks, environments.
+**Goal.** For **one story**: declare the test split, the fixtures, the mocks, the environments, and the assertion targets. This is Hawkeye's contract Shuri implements against. No story enters dev without one.
+
+Hawkeye drives. Runs at the start of every story (advisory; can be relaxed only when `tea.toml` says so).
 
 ## Inputs
+
 - `.wize/solutioning/stories/{epic}/{story}.md`
 - `.wize/solutioning/architecture.md`
+- `.wize/implementation/tea/risk-profile.md`
+- Overlay test playbooks if active:
+  - `web-overlay/playbooks/playwright-vitest.md`
+  - `app-overlay/playbooks/detox-maestro.md`
 
 ## Output
+
 - `.wize/implementation/tea/{epic}/{story}/design.md`
 
-## YAML frontmatter
+## Steps
+
+### 1. Read the story; map every AC
+
+For each AC, write **one assertion-shape sentence**: *"There will be a {kind} test that does {what} and expects {observable}."*
+
+### 2. Pick the test split
+
+Defaults (from `playwright-vitest.md` / `detox-maestro.md`):
+- **Low-risk story:** 70% unit / 20% integration / 10% E2E.
+- **Risk-profile flagged story (R-1..R-3):** add 1–2 dedicated E2E + integration for the risk area.
+- **UI-only story:** 60% unit / 30% component (Testing Library) / 10% E2E.
+- **Server-only story:** 80% unit / 20% integration; no E2E unless an upstream consumer story bundles it.
+
+### 3. Declare fixtures + mocks
+
+- Fixtures: known users, known DB rows, known files.
+- Mocks: external services at the network boundary (MSW). Don't mock the unit under test.
+
+### 4. Environment
+
+- Where it runs (local sim, headless emulator, real device farm).
+- Network conditions (offline / 3G slow / lossy WiFi).
+- OS / browser matrix (from `device-matrix.md` or playwright projects).
+
+### 5. Edge cases (cheap; pay back × 10)
+
+List 3–7 edge cases the ACs don't name but the user might hit:
+- Empty / max-length inputs.
+- IME / paste / autofill.
+- Offline mid-action.
+- Concurrent users on the same resource.
+- Time-zone / DST.
+- Localized number/currency.
+
+Each gets a test of its own (usually unit).
+
+### 6. Hand off
+
+Mark `status: ready-for-dev` in the design.md frontmatter. Shuri reads before starting.
+
+## YAML frontmatter (canonical)
+
 ```yaml
 ---
 gate: design
-story_id: …
-ac_ids: [AC-1, AC-2, …]
+story_id: E01-S03
+ac_ids: [AC-02-1, AC-02-2]
+status: PASS
+created_at: 2026-06-11T12:00:00Z
 test_split:
-  unit: count + brief description
-  integration: count + brief description
-  e2e: count + brief description
-fixtures: [...]
-mocks: [...]
-environment: dev|staging|isolated
+  unit: { count: 4, description: "validation, server-action contract, error mapper, mailer payload" }
+  integration: { count: 1, description: "server action calls mailer with right args, against MSW" }
+  e2e: { count: 1, description: "happy path; Playwright @chromium @ios" }
+fixtures:
+  - "new-admin user"
+  - "empty team"
+mocks:
+  - "Resend via MSW"
+  - "Auth session via fixture cookie"
+environment: "local + Playwright project chromium + ios"
+risk_links: [R-1]
+edges:
+  - "invalid email rules: blank, missing @, weird IME chars"
+  - "duplicate teammate email"
+  - "offline at submit time"
 ---
 ```
 
-## Body
-Plain-English rationale + edge-case list.
+## Body of `design.md`
+
+```markdown
+## Per-AC assertion shapes
+
+- **AC-02-1**: Vitest unit on `validateInviteEmail()` → returns `{ ok: true }` for `name+tag@example.com`. Vitest integration on `inviteTeammate()` server action → asserts `mailer.send` called once with `{ to: 'name@example.com', template: 'team-invite' }`. Playwright E2E → clicks "Send invite", asserts `[data-testid="invite-sent-banner"]` appears within 1s.
+
+- **AC-02-2**: Vitest unit on `validateInviteEmail()` → returns `{ ok: false, code: 'invalid_format', field: 'email' }` for empty/no-@. Component test (Testing Library) on `<InviteForm>` → asserts the input's `aria-describedby` error region announces "Enter a valid email."
+
+## Edge cases (additional tests)
+
+- E1: Empty email — `validateInviteEmail('')` → `invalid_format`.
+- E2: 254-char local part — boundary check; expect graceful clipping.
+- E3: Same email submitted twice — second call hits `inviteTeammate()`, asserts second insert is a no-op (idempotency key based on `(team_id, email)`).
+- E4: Offline at submit — Playwright `context.setOffline(true)` after click; banner shows "We'll retry when you're back online."
+
+## Run plan
+- On every PR: full unit + integration; E2E `@smoke` tag only (≤ 30s).
+- Nightly: full E2E suite + Lighthouse baseline.
+```
+
+## Anti-patterns Hawkeye rejects
+
+- **`design.md` written after dev started.** Then the story slipped through; flag.
+- **One test per AC, no edges.** Edges are where users live.
+- **Mocking the unit under test.** You'd be testing the mock.
+- **E2E that test the happy path only.** Cover failure too.
+- **Selectors by visible text in a multilingual app.** Use `data-testid` or `role` with locale-aware patterns.
+
+## Hand-off
+
+> Test design for E01-S03 at `.wize/implementation/tea/E01-S03/design.md`. 4 unit, 1 integration, 1 E2E, plus 4 edges. Shuri can start; I'll check `tea-trace.md` against this when the PR opens.