wize-dev-kit 0.16.0 → 0.17.0

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

@@ -0,0 +1,64 @@
+---
+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

@@ -0,0 +1,40 @@
+---
+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

@@ -0,0 +1,43 @@
+# 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

@@ -0,0 +1,100 @@
+---
+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-code-review/workflow.md

@@ -1,24 +1,66 @@
 ---
+
 code: wize-code-review
+description: "Use quando um PR estiver aberto e precisar de revisão de código por pares focada em saúde do código."
 name: Code Review
 phase: 4-implementation
-owner: wize-agent-dev   # Shuri (peer Shuri — done at PR open time)
-status: stub
+owner: wize-agent-dev   # Shuri (peer review)
+status: ready
 ---
 
 # Code Review
 
-**Goal.** Self/peer review focused on code health. Separate from Hawkeye's story review.
+**Goal.** Review code changes adversarially using parallel review layers and structured triage into actionable categories.
+
+This is **Shuri's peer code review** — separate from Hawkeye's `wize-tea-review` (which audits AC fulfillment). Both run on every story PR; they are complementary.
+
+## When to run
+
+Every PR that ships code. Quick-dev PRs get a lighter review (skip architecture checks unless they touched architecture).
 
-## What this checks
-- Naming, structure, dead code
-- Test coverage and quality (not just presence)
-- Security obvious-misses
-- Performance obvious-misses
-- Architectural drift (call Tony if found)
+## Inputs
 
-## What this does NOT check
-- AC fulfillment — that's Hawkeye's `trace` + `review` + `gate`.
+- The diff, PR, branch, or commit range to review.
+- The spec/story file for context (optional but recommended).
+- Existing code style and project context from `.wize/knowledge/document-project/`.
 
 ## Outputs
-- Inline comments / suggestions on the diff.
+
+- Inline-style findings presented in the conversation.
+- Optional patch application if the user chooses to fix findings now.
+- Updated story file with a `### Review Findings` section when a spec file is provided.
+- Updated sprint status when a story key is discovered.
+
+## Workflow architecture
+
+This skill uses **step-file architecture**:
+
+- Each step is self-contained and followed exactly.
+- Sequential enforcement: complete steps in order, no skipping.
+- State tracked in frontmatter variables set at runtime.
+- Append-only building of findings.
+
+## Critical rules
+
+- **Read completely** each step file before acting.
+- **Never** load multiple step files simultaneously.
+- **Always** halt at checkpoints and wait for human input.
+- Use CWD-relative `path:line` for every code reference.
+
+## On activation
+
+1. Load `.wize/config/project.toml` and `.wize/config/user.toml`.
+2. Resolve `user_name`, `communication_language`, `document_output_language`, `implementation_artifacts`, `planning_artifacts`.
+3. Greet the user in `communication_language`.
+4. Read fully and follow `./steps/step-01-gather-context.md`.
+
+## Steps
+
+1. `step-01-gather-context.md` — identify the diff source, construct `{diff_output}`, set `{review_mode}` and `{spec_file}`.
+2. `step-02-review.md` — launch parallel review layers (Blind Hunter, Edge Case Hunter, Acceptance Auditor).
+3. `step-03-triage.md` — normalize, deduplicate, and classify findings into `decision_needed`, `patch`, `defer`, `dismiss`.
+4. `step-04-present.md` — present findings, resolve decisions, apply patches, update story status.
+
+## Hand-off
+
+> Code review complete for `{story_key or change}`. `{decision_needed}` decision(s), `{patch}` patch(es), `{defer}` deferred, `{dismissed}` dismissed as noise. Next: re-run review or continue to `wize-tea-review` (Hawkeye).

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

@@ -0,0 +1,93 @@
+---
+
+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-create-story/workflow.md

@@ -1,27 +1,171 @@
 ---
+
 code: wize-create-story
+description: "Use quando um epic estiver definido e precisar criar uma story individual com acceptance criteria detalhados."
 name: Create Story
 phase: 4-implementation
 owner: wize-agent-architect   # Tony writes; Shuri may refine
-status: stub
+status: ready
 ---
 
 # Create Story
 
-**Goal.** Author one Pull-Request-sized story unit with crisp acceptance criteria.
+**Goal.** Author one Pull-Request-sized story with crisp acceptance criteria, named touch-points, and a contract for Hawkeye's `tea-design.md`. This is the single most-edited artifact in the lifecycle; make it useful.
+
+Tony drives. Shuri reads and proposes refinements before pulling the story.
+
+> **No estimates.** Never attach a time or effort estimate (hours, days, story points, S/M/L/XL) to a story — at any step. AI development speed has made them noise that only burns time and tokens. The only sizing question is binary: **does it fit one PR?** If not, slice it. Nothing else.
+
+## When to use
+
+- New story splits from an epic (most common — done in `wize-create-epics-and-stories`).
+- A story that comes in mid-sprint and needs a quick scaffold.
+- A `tea-gate` waived rationale created a follow-up story.
 
 ## Inputs
+
+Read central docs first, expand by dependency; don't pad with unrelated files:
+
+- `AGENTS.md` + `.wize/config/project.toml` — profiles, languages, conventions.
 - `.wize/solutioning/architecture.md`
 - `.wize/solutioning/epics/{epic}.md`
-- (optional) UX screen reference
+- `.wize/planning/prd.md` (the AC list)
+- `.wize/knowledge/document-project/` (brownfield baseline, if present)
+- (optional) `.wize/planning/ux/ux-design/{screen}.md`
+
+## Output
 
-## Outputs
 - `.wize/solutioning/stories/{epic}/{story-id}.md`
 
-## Story template
-(See `wize-create-epics-and-stories` for the canonical template.)
+## Steps
+
+### 1. Name it by outcome
+
+Verb-led, user-visible. *"Onboarding: invite first teammate"* not *"Build invite form."*
+
+### 2. Frontmatter
+
+```yaml
+---
+story_id: E01-S03
+epic: 01-onboarding
+status: ready-for-dev
+priority: 2          # 1=now, 2=next, 3=later
+linked_screens: [onboarding-step-1, invite-modal]
+linked_acs: [AC-02-1, AC-02-2]
+---
+```
+
+### 3. Context (3–5 lines)
+
+What place this story occupies in the user journey, why it matters here, what it depends on.
+
+### 4. ACs (lifted from PRD; not reworded)
+
+Don't reword PRD ACs in a story — copy them verbatim. If they're not crisp enough, fix in the PRD first.
+
+### 5. Out of scope
+
+Explicit. Other ACs the user might think this story touches, with a one-line reason it's not here.
+
+### 6. Sources of truth
+
+List the exact docs Shuri must read before coding: `AGENTS.md`, `project.toml`, `document-project/*`, the parent epic, `architecture.md`, the linked screen, the TEA test contract, and the related code + tests already on this path.
+
+### 7. Restrictions
+
+Beyond out-of-scope: name **protected behaviors** (what must not change), **compatibility** constraints (keys, contracts, migrations), and **security** constraints (boundary validation, authz). No silent scope creep — log recommended extras separately.
+
+### 8. Validation contract
+
+Declare the **AC → test** map and the **required checks** (unit / integration / e2e, lint, format, type-check, build, security when applicable) plus which UI states (loading / empty / error) must be asserted. Hawkeye writes the real `tea-design.md`, but this is the binding shape it fills.
+
+### 9. Notes for Shuri
+
+- Touch points: files Shuri will likely edit.
+- Reuse: components from `design-system` already named.
+- `testid` map: names Hawkeye expects.
+- Edge cases worth flagging (only ones not derivable from ACs).
+
+### 10. Notes for Hawkeye
+
+A one-paragraph hint: suggested split, fixtures, mocks, environment. Hawkeye writes the real `tea-design.md` but reads this hint.
+
+## INVEST rules
+
+Every story passes:
+
+- **I**ndependent.
+- **N**egotiable.
+- **V**aluable.
+- **S**mall (≤ 1 PR) — the *only* sizing test; if it doesn't fit one PR, slice.
+- **T**estable.
+
+(INVEST's "Estimable" is dropped on purpose — see **No estimates** above. We don't size in time or points.)
+
+If any letter fails, fix before queueing.
+
+## Full story template
+
+```markdown
+---
+story_id: E01-S03
+epic: 01-onboarding
+status: ready-for-dev
+priority: 2
+linked_screens: [onboarding-step-1, invite-modal]
+linked_acs: [AC-02-1, AC-02-2]
+---
+
+# Story: Onboarding step 1 — invite first teammate
+
+## Context
+After sign-up the admin lands on `/onboarding`. This story implements the first
+moment-of-truth from scenario S1: inviting the first teammate.
+
+## Sources of truth (Shuri reads before coding)
+- `AGENTS.md` + `.wize/config/project.toml` · `.wize/knowledge/document-project/*`.
+- `prd.md` (AC source) · `architecture.md` · `ux-design/onboarding-step-1.md` · parent epic `01-onboarding.md`.
+- The TEA test contract for this story · related code + tests already on this path.
+
+## Acceptance criteria
+- **AC-02-1:** Given a new admin on `/onboarding`, When they enter a valid email and click "Send invite", Then a `teammate_invited` event fires and the screen advances to "Invite sent" within 1s.
+- **AC-02-2:** Given an invalid email, When the user blurs the field, Then error text appears (200ms) identifying which rule failed.
+
+## Restrictions
+- **Out of scope:** bulk invite (multiple emails) → E01-S07; custom invite message → E02-S03; "Skip for now" button — not a moment-of-truth path; out.
+- **Protected behaviors:** existing sign-up + session flow must not change.
+- **Compatibility:** `(team_id, email)` composite idempotency key — don't break existing invite rows.
+- **Security:** validate email at the server boundary; auth context required on `inviteTeammate`.
+
+## Notes for Shuri (Dev)
+- Touch points: `app/(onboarding)/invite/page.tsx`, `lib/email/send-invite.ts`, new server action `inviteTeammate`.
+- Reuse: `Button` (primary), `Input`, `Banner` (success/error) from design-system.
+- testid: `invite-form`, `invite-email`, `invite-cta`, `invite-sent-banner`.
+
+## Validation contract
+- **AC → test:** AC-02-1 → E2E happy path (Playwright @chromium @ios) + unit `validateInviteEmail`; AC-02-2 → unit invalid-email rules + component error-state.
+- **Required checks:** the unit/integration/E2E split Hawkeye declares below, plus lint, format, type-check, build. Authz asserted on the server action.
+- **States:** loading, empty, error rendered and asserted.
+
+## Notes for Hawkeye (TEA)
+Suggested split: 4 unit, 1 integration, 1 E2E.
+- Unit: validateInviteEmail, mailer payload, server action error mapping, retry policy.
+- Integration: server action calls mailer with right args (MSW on Resend).
+- E2E: happy path on Playwright @chromium @ios.
+- Risk: R-1 (mailer) — extra E2E asserts banner within 1s of click.
+
+## Done means
+Every AC has a passing test (mapped above), gate PASS/CONCERNS, story `status: ready-for-review`, knowledge axes updated if touched.
+```
+
+## Anti-patterns Tony rejects
+
+- **ACs reworded from PRD.** Source-of-truth drift.
+- **Stories with no touch points.** Shuri spends an hour finding the files.
+- **No notes for Hawkeye.** TEA designs in the dark.
+- **Stories named by feature** ("Add invite button") — name by **outcome**.
+
+## Hand-off
 
-## Rules
-- One story = one PR. If two, split.
-- Each AC must be testable. If Hawkeye can't write a test for it, rewrite the AC.
-- "Out of scope" is mandatory. Force the cut.
+> Story E01-S03 ready. Shuri, pull when sprint allows. Hawkeye, `tea-design.md` for this story whenever you're ready.