wize-dev-kit 0.14.0 → 0.16.0

package/src/method-skills/2-plan-workflows/wize-ux-design/workflow.md

@@ -1,172 +1,66 @@
 ---
-
 code: wize-ux-design
-description: "Use quando os cenários UX estiverem prontos e precisar produzir especificações página por página para arquitetura e implementação."
 name: UX Design
 phase: 2-plan
 owner: wize-agent-ux-designer   # Mantis
 absorbs: "WDS Freya — Phase 4 (Page Specs)"
-status: ready
+status: stub
 ---
 
 # UX Design
 
-**Goal.** Turn scenarios into page-by-page specifications Tony can architect against and Shuri can implement. One spec per screen. Every spec answers: purpose, primary action, layout, content, interactions, states (loading/empty/error/success/disabled), accessibility, and metrics.
-
-Mantis drives. Output lands in `.wize/planning/ux/ux-design/{screen-name}.md`.
+**Goal.** Page-by-page specifications. Each screen documents layout, content, interactions, edge/empty/error states.
 
 ## Inputs
-
-- `.wize/planning/ux/ux-scenarios.md` (every screen traces back to ≥ 1 scenario)
-- `.wize/planning/prd.md` (every screen advances at least one AC)
-- `.wize/solutioning/design-system/` (when Mantis already wrote tokens; otherwise this runs in parallel with `wize-design-system`)
-- Overlay playbooks if active:
-  - `web-overlay/playbooks/wcag-aa.md`, `responsive-breakpoints.md`, `semantic-html.md`
-  - `app-overlay/playbooks/apple-hig.md`, `material-design-3.md`, `touch-targets-and-gestures.md`, `permissions-ux.md`
+- `.wize/planning/ux/ux-scenarios.md`
+- `.wize/planning/prd.md`
 
 ## Outputs
-
 - `.wize/planning/ux/ux-design/{screen-name}.md` (one per screen)
-- `.wize/planning/ux/ux-design/index.md` (map of screens → scenarios → PRD ACs)
-
-## Steps
-
-### 1. Enumerate the screens
-
-From the scenarios, list every screen needed to deliver the moment-of-truth. Name them by role + state: `signup-empty.md`, `signup-error.md`, `team-list-with-members.md`, `team-list-empty.md`. Empty/error/loading states are screens.
-
-### 2. Per screen: fill the spec template
 
-For each screen, write the spec below. Stay disciplined; if a section is empty, ask why.
-
-### 3. Write the index
-
-`index.md` is a single table mapping screen → scenarios touched → PRD ACs advanced. Tony reads this first; Hawkeye references it in `tea-design.md`.
-
-### 4. Hand off
-
-Mark `status: ready-for-architecture` on each spec. Notify Wizer; Tony reads next.
-
-## Spec template (one file per screen)
+## Per-screen template
 
 ```markdown
 ---
-screen: signup-empty
-status: ready-for-architecture
-owner: Mantis
-linked_scenarios: [S1]
-linked_acs: [AC-01-1, AC-01-2]
+screen: {{name}}
+linked_scenario: ux-scenarios.md#scenario-N
 ---
 
-# Sign up (empty state)
+# {{Screen name}}
 
 ## Purpose
-First contact: a manager wants to create an account. The goal of *this* screen is to collect work email + password with minimum friction, in service of scenario S1 moment-of-truth (3 invites within 5 minutes).
+…
 
 ## Primary user action
-Submit the form (CTA: "Create account").
-
-## Layout (ASCII or Mermaid)
+…
 
-(web overlay)
+## Layout (ASCII wireframe or description)
 ```
-┌─────────────────────────────────────────────────┐
-│ Wize logo                          [Sign in →]  │
-├─────────────────────────────────────────────────┤
-│                                                 │
-│           Create your team's account            │
-│           ──────────────────────────            │
-│           [ Work email           ]              │
-│           [ Password (12+)       ]              │
-│                                                 │
-│           [    Create account    ]              │
-│                                                 │
-│           Already a member? Sign in              │
-│                                                 │
-└─────────────────────────────────────────────────┘
+┌───────────────────────────────────────┐
+│ Header                                │
+├───────────────────────────────────────┤
+│ Content                               │
+└───────────────────────────────────────┘
 ```
 
-(app overlay note: stacked, top-aligned, system back disabled.)
-
-## Content (copy)
-
-- Headline: "Create your team's account"
-- Sub: (none — keep the screen empty for focus)
-- Field 1 label: "Work email"
-- Field 1 placeholder: "name@yourcompany.com"
-- Field 2 label: "Password"
-- Field 2 helper text: "At least 12 characters."
-- CTA: "Create account"
-- Secondary: "Already a member? Sign in" → routes to /signin
+## Content
+- Headline: …
+- Body: …
+- CTA: …
 
 ## Interactions
-
-- Click CTA with valid form → submit; show loading state; redirect on success.
-- Click CTA with invalid form → set focus to first invalid field; show error region.
-- Tab order: email → password → CTA → "Sign in" link.
-- Enter on either field submits if both are valid.
+- Click {{element}} → {{outcome}}
 
 ## States
-
-- **Loading:** CTA shows spinner; button is disabled; inputs remain editable.
-- **Empty (this state):** placeholders visible; CTA disabled until both fields non-empty.
-- **Error (inline per field):** error region appears under each field, `role="alert"`, identifies the rule and the fix.
-- **Error (global):** Banner above headline if the back-end fails with a non-field error; provides a "retry" action.
-- **Success:** redirect; no flash. The next screen owns acknowledgement.
-- **Disabled:** CTA opacity 0.4; aria-disabled="true"; tooltip *"Fill both fields to continue"*.
+- Loading: …
+- Empty: …
+- Error: …
+- Success: …
 
 ## Accessibility notes
-
-(web overlay)
-- Both inputs have visible persistent labels (no placeholder-only).
-- `lang="en"` on `<html>`.
-- Error region: per-field `aria-describedby`, ALL `role="alert"` after first submit only.
-- Contrast pairs all ≥ 4.5:1 in light mode, ≥ 4.5:1 in dark mode.
-- 200% zoom: no horizontal scroll on 360px viewport.
-- Skip link absent (no main nav before).
-
-(app overlay)
-- Apple HIG / Material 3 systemic input components.
-- Dynamic Type / font scale: layout reflows at largest accessibility size; CTA pinned to bottom-safe-area.
-- Touch targets ≥ 44pt (iOS) / 48dp (Android).
-- VoiceOver order: headline → email → password → CTA → secondary link.
-
-## Metrics
-
-- Event `signup_completed` (Q7 success quote): fires after redirect.
-- Event `signup_error_shown {rule}`: fires on inline error.
-- Event `signup_abandoned`: fires on `beforeunload` if form had focus and CTA never fired.
-
-## Open questions for Tony
-
-- Should we use Auth0 hosted UI or our own form? (UX-decision is to keep our own; Tony decides feasibility.)
-- Magic-link as an alternative path? Out of scope per PRD; Mantis recommends putting in *Out*.
+- (web-overlay) WCAG …
+- (app-overlay) HIG / Material …
 ```
 
-## Index template
-
-```markdown
-# UX Design — index
-
-| Screen | Scenarios | PRD ACs |
-|---|---|---|
-| signup-empty | S1 | AC-01-1, AC-01-2 |
-| signup-error | S1 | AC-01-2 |
-| onboarding-step-1 | S1 | AC-02-1 |
-| team-list-empty | S1, S2 | AC-03-1 |
-| team-list-with-members | S1, S2 | AC-03-2, AC-03-3 |
-| invite-modal | S1, S2 | AC-02-2, AC-02-3 |
-```
-
-## Anti-patterns Mantis rejects
-
-- **Specs without states.** A screen with no empty/error spec is half a spec.
-- **Copy as marketing tone.** Use the user's voice. Cut "world-class," "delightful," "seamless."
-- **Mystery icons.** Icons need accessible labels; if you can't name it, draw a word next to it.
-- **Hover-only affordances on touch.** Spec the non-hover equivalent.
-- **Touch targets < platform minimum.** 24×24 CSS px on web (WCAG 2.5.8), 44pt iOS, 48dp Android — non-negotiable.
-- **Screens that don't trace to scenarios + PRD ACs.** If you can't fill the index row, the screen isn't justified.
-
 ## Hand-off
-
-> UX specs are at `.wize/planning/ux/ux-design/`. Index points screen → scenario → AC. Tony, you can start `wize-create-architecture` now; the moment-of-truth lines in scenarios tell you which interactions are load-bearing. Hawkeye, `tea-design.md` should index by screen to keep test design and UI aligned.
+"Tony, screen specs in `.wize/planning/ux/ux-design/`. Architecture time."

package/src/method-skills/2-plan-workflows/wize-ux-scenarios/workflow.md

@@ -1,126 +1,48 @@
 ---
-
 code: wize-ux-scenarios
-description: "Use quando o PRD estiver validado e precisar produzir o mapa de cenários UX que ancora todo o design."
 name: UX Scenarios
 phase: 2-plan
 owner: wize-agent-ux-designer   # Mantis (absorbs WDS Freya)
 absorbs: "WDS Freya — Phase 3 (8-question dialog)"
-status: ready
+status: stub
 ---
 
 # UX Scenarios
 
-**Goal.** Produce a scenario map that anchors all UX work. Eight focused questions; one short answer each. Scenarios are pieces of behavior, not personas — they're how *this* user, in *this* state, tries to accomplish *that* JTBD.
-
-Mantis drives. Output lands in `.wize/planning/ux/ux-scenarios.md`. It's the bridge from PM intent (PRD) to designer concreteness (next workflow: `wize-ux-design`).
+**Goal.** Produce the scenario map that anchors all UX work. Eight focused questions; one answer each.
 
 ## Inputs
-
-- `.wize/planning/prd.md` (validated)
-- `.wize/planning/ux/trigger-map.md` (Pepper)
+- `.wize/planning/prd.md`
+- `.wize/planning/ux/trigger-map.md`
 - `.wize/planning/brief.md`
 
 ## Outputs
-
 - `.wize/planning/ux/ux-scenarios.md`
 
-## Steps
-
-### 1. Identify the scenarios
-
-A scenario = one (user, state, JTBD) tuple where the product earns or loses. Aim for **3–8 scenarios** that, taken together, cover all backbone stories in the PRD.
-
-Rules:
-- One sentence each at this stage.
-- Verb-led. *"New manager onboards their first team."* Not *"Manager onboarding."*
-- Distinct. If two scenarios share trigger + state, collapse them.
-
-### 2. Run the 8-question dialog per scenario (WDS Freya)
-
-For each scenario, answer the eight questions. One paragraph per answer. No filler. Cite trigger-map row when relevant.
+## The 8 questions (WDS dialog)
 
 1. **Who is the user, in one sentence?**
-   Role + context. *"A 38-year-old engineering manager at a 25-person SaaS, primarily on desktop, sometimes phone."*
-
-2. **What state are they in when they arrive?**
-   Emotion + situational context. *"It's Monday morning. They just got CTO's request to onboard 3 hires this sprint. They're alt-tabbing between Slack and Linear."*
-
-3. **What are they trying to accomplish?** (JTBD)
-   *"Add three teammates and assign each to the right project before the team standup at 10am."* Concrete.
-
+2. **What state are they in when they arrive?** (emotional, contextual)
+3. **What are they trying to accomplish?** (job-to-be-done)
 4. **What would they do without our product today?**
-   *"Slack screenshots of the project list to each new hire; have them sign up individually; cross-check who landed where."*
-
 5. **What's the moment of truth — when they decide it works?**
-   *"The first time they see all three names in the team list with the right project tags, in under 5 minutes."*
-
 6. **What's the failure mode — when do they walk away?**
-   *"If they can't tell whether the invite arrived. If the invite email looks like spam. If they have to leave the page to find someone's email."*
-
 7. **What does success look like to them, in their words?**
-   *"It just worked. I sent the invites, they signed up, they were on the right project."* (Imagine the future quote.)
-
 8. **What's the next thing we want them to do?**
-   *"Open the project where the first teammate landed and verify the access works."*
 
-### 3. Cross-link to the PRD
-
-For each scenario, list the **backbone story IDs** + **AC IDs** it touches. Mantis won't write specs for a scenario the PRD doesn't cover (it'd be scope creep); Hill won't sign off on a story the scenarios don't surface (it'd be over-spec).
-
-### 4. Hand off to UX Design
-
-Mark `status: ready-for-design`. Wizer pings Mantis to start `wize-ux-design`, where each scenario becomes one or more page specs.
-
-## Output template
+## Output structure
 
 ```markdown
----
-status: ready-for-design
-owner: Mantis
-created: YYYY-MM-DD
-covers_prd_stories: [E01, E02, E04]
----
-
-# UX Scenarios — {{project_name}}
-
-## Scenario 1: New manager onboards their first team
-
-- **Trigger-map row:** 1 (Sign up), 2 (Invite first teammate)
-- **PRD stories:** E01, E02
-- **AC IDs touched:** AC-01-1, AC-01-2, AC-02-1, AC-02-3
-
-**Q1 — Who:** A 38-year-old engineering manager at a 25-person SaaS, primarily on desktop, sometimes phone.
-**Q2 — State:** It's Monday morning. They just got CTO's request to onboard 3 hires this sprint. They're alt-tabbing between Slack and Linear.
-**Q3 — JTBD:** Add three teammates and assign each to the right project before the team standup at 10am.
-**Q4 — Today:** Slack screenshots of the project list to each new hire; have them sign up individually; cross-check who landed where.
-**Q5 — Moment of truth:** The first time they see all three names in the team list with the right project tags, under 5 minutes.
-**Q6 — Failure mode:** Can't tell whether the invite arrived; the email looks like spam; they have to leave the page to find someone's email.
-**Q7 — Success in their words:** "It just worked. I sent the invites, they signed up, they were on the right project."
-**Q8 — Next thing:** Open the project where the first teammate landed and verify access.
-
-## Scenario 2: Returning admin adds a fourth member months later
+# UX Scenarios
 
-(…)
+## Scenario 1: {{name}}
 
-## Coverage check
+- Q1 …
+- Q2 …
+- …
 
-| PRD story | Scenarios |
-|---|---|
-| E01 (Sign up) | S1 |
-| E02 (Invite) | S1, S2 |
-| E03 (Switch project) | S2 |
-| E04 (Dashboard) | S1 |
+## Scenario N: …
 ```
 
-## Anti-patterns Mantis rejects
-
-- **Personas instead of scenarios.** Mantis cares what people *do*, not who they are in the abstract.
-- **Scenarios with no emotion or context.** "User wants to sign up." — that's a backbone story restated. The point is the *state*.
-- **JTBD written as features.** "Wants the dashboard." Wrong layer. Reword to the goal: "Wants to know if the team is healthy at a glance."
-- **Q5 ("moment of truth") that's actually a feature description.** It should be the user's perception, not the UI.
-- **More than 8 scenarios.** Two of them are duplicates. Find which.
-
 ## Hand-off
-
-> Scenarios are in `.wize/planning/ux/ux-scenarios.md`. They cover E01–E04. Next: page specs in `.wize/planning/ux/ux-design/` (one per screen). Tony, when you read these, the moment-of-truth lines tell you which interactions are load-bearing.
+"Mantis → Mantis": run `wize-ux-design` next.

package/src/method-skills/2-plan-workflows/wize-validate-prd/workflow.md

@@ -1,123 +1,27 @@
 ---
-
 code: wize-validate-prd
-description: "Use quando o PRD estiver pronto para validação e precisar decidir se ele pode avançar para Solutioning."
 name: Validate PRD
 phase: 2-plan
-owner: wize-agent-pm   # Maria Hill (with Pepper, Mantis, Fury input)
-status: ready
+owner: wize-agent-pm   # Maria Hill (with Pepper + Mantis + Fury input)
+status: stub
 ---
 
 # Validate PRD
 
-**Goal.** Decide whether the PRD is ready to leave Plan and enter Solutioning. Catch ambiguity before architecture is wasted on it. Cheap step; saves multiples of itself downstream.
-
-Maria Hill chairs. Pepper, Mantis, Fury contribute. Output is either `validated: true` written to `prd.md` or a punch list routed back to authors.
-
-## When to run
-
-After `wize-create-prd` produces `status: ready-for-validation`. Run once per major PRD change.
+**Goal.** Make sure the PRD is ready to leave Plan and enter Solutioning. Catch ambiguity before architecture is wasted on it.
 
 ## Inputs
-
 - `.wize/planning/prd.md`
-- `.wize/planning/brief.md`
-- `.wize/planning/ux/trigger-map.md`
-- `.wize/planning/research.md` (when present)
-- `.wize/planning/tech-vision.md` (when Fury already wrote one)
 
 ## Outputs
+- Inline edits + a validation log appended to `prd.md`.
 
-- In-place edits to `prd.md` (validators add a "Validation log" section).
-- If validated: `prd.md` frontmatter flips to `status: validated`.
-- If not: a punch list, each item routed back to the owning agent.
-
-## Checklist (Maria Hill runs this)
-
-### Completeness
-- [ ] Vision sentence present and matches the brief.
-- [ ] 3–5 goals; each measurable; each tied to a trigger-map row.
-- [ ] Scope `In` and `Out` both populated; `Out` items have reasons.
-- [ ] Backbone stories cover every In-scope item.
-- [ ] Every In-scope item has 3–7 ACs.
-- [ ] Constraints + Assumptions + Dependencies all named.
-- [ ] NFR pointer present.
-- [ ] Open questions: each has an owner + deadline.
-
-### Quality
-- [ ] Every AC is observable (testable by Hawkeye without ambiguity).
-- [ ] No AC contains the word "easy", "intuitive", "responsive" without a numeric criterion.
-- [ ] INVEST: every backbone story passes (independent, negotiable, valuable, small, testable) — "Estimable" is dropped; we don't estimate, we only check it fits one PR.
-- [ ] No goal repeats a brief constraint as if it were a goal.
-
-### Cross-checks
-- [ ] **Pepper:** every goal anchors on a row of the trigger map.
-- [ ] **Mantis:** every screen implied by the ACs is addressable in UX (no AC requires a UI the team hasn't agreed exists).
-- [ ] **Fury:** the PRD's NFR pointer doesn't contradict the tech-vision.
-- [ ] **Hawkeye preview:** at least the gate strategy is mentioned (advisory vs enforcing) for visibility.
-
-### Risk
-- [ ] No open question is marked `blocker` AND has a deadline past the PRD validation date.
-- [ ] Any assumption that, if wrong, kills > 30% of the scope has a verification plan.
-
-## Decision
-
-After the checklist:
-
-- **Validated** → flip frontmatter to `status: validated`. Append a Validation log block to `prd.md` with date + each signatory.
-- **Concerns** → write specific fix-asks per agent. Each fix-ask is concrete (line ref + what to change).
-- **Reject** → rare. Use when the brief itself is wrong; loop back to Pepper.
-
-## Validation log template (appended to `prd.md`)
-
-```markdown
-## Validation log — YYYY-MM-DD
-
-**Status:** validated
-
-**Signatories**
-- Maria Hill (PM)  — concerns: none
-- Pepper Potts (Analyst) — concerns: trigger-map row 3 needs a stronger signal name, will update.
-- Mantis (UX) — concerns: none, UX work starts next.
-- Fury (Solution Strategy) — concerns: none. NFR pointer confirmed.
-
-**Notes**
-- Open question "Brazil-only beta?" was answered by sales lead — added to *Out of scope: global launch* with rationale.
-```
-
-## Punch-list template (when not validated)
-
-```markdown
-## Validation punch list — YYYY-MM-DD
-
-**Status:** changes required
-
-**By Maria Hill — author rewrites:**
-- `AC-02-3`: "loads fast" is not observable. Rewrite with numeric target tied to Fury's NFRs.
-- Backbone story E04 fails INVEST-S (too large). Split into 2 stories.
-
-**By Pepper:**
-- Goal 2 is not anchored on a trigger-map row. Add row reference or remove.
-
-**By Mantis:**
-- AC-01-4 implies a "preview" screen that isn't in any UX list. Either spec the screen or cut the AC.
-
-**By Fury:**
-- NFR pointer cites old version of nfr-principles.md. Update.
-```
-
-## Anti-patterns
-
-- "Looks good to me" with no checklist run. The validation only counts if checked.
-- Validating to keep the schedule, knowing concerns are open. Document the concern.
-- Validating with no Hawkeye preview at all. Even a one-line gate strategy reference matters.
-
-## Hand-off
-
-If validated:
-
-> PRD validated. Mantis, you're up: `wize-ux-scenarios`. Fury, write or refresh `tech-vision.md` so Tony can read both.
-
-If not:
+## Checklist
+- [ ] Every scope item has measurable ACs.
+- [ ] No "TBD" in goals or constraints.
+- [ ] Mantis confirms UX is addressable.
+- [ ] Fury approves stack-family direction (or has explicit reason not to yet).
+- [ ] No open questions with `blocker` priority remain.
 
-> PRD not yet validated. Punch list lives at the bottom of `prd.md`. {{Author}} fixes by {{date}}; we re-run validation.
+## Outcome
+Either `validated: true` (timestamp + signatories) or list of fix-asks routed back to the right agent.

package/src/method-skills/3-solutioning/wize-check-implementation-readiness/workflow.md

@@ -1,114 +1,22 @@
 ---
-
 code: wize-check-implementation-readiness
-description: "Use quando a arquitetura e as stories estiverem prontas e precisar verificar se o projeto está pronto para entrar em implementação."
 name: Check Implementation Readiness
 phase: 3-solutioning
-owner: wize-agent-architect   # Tony Stark (with Hawkeye + Hill)
-status: ready
+owner: wize-agent-architect   # Tony Stark (with Hawkeye)
+status: stub
 ---
 
 # Check Implementation Readiness
 
-**Goal.** Before any story enters dev, confirm everything is in place. This is the **gate at the end of Phase 3**. Cheap; saves multiples of itself downstream.
-
-Tony chairs. Hill and Hawkeye sign off. Pepper and Mantis answer if pulled in.
-
-## Inputs
-
-- `.wize/planning/prd.md` (validated)
-- `.wize/planning/ux/ux-design/` + `index.md`
-- `.wize/planning/tech-vision.md`
-- `.wize/planning/nfr-principles.md`
-- `.wize/solutioning/architecture.md`
-- `.wize/solutioning/adrs/`
-- `.wize/solutioning/design-system/`
-- `.wize/solutioning/epics/` + `stories/`
-- `.wize/implementation/tea/risk-profile.md` (Hawkeye)
-- `.wize/config/tea.toml` (policy choice)
-
-## Outputs
-
-- `.wize/solutioning/readiness-{YYYY-MM-DD}.md` — checklist result + signoffs.
-
-## Checklist (Tony chairs)
-
-### Planning artifacts
-- [ ] PRD `status: validated`.
-- [ ] All open questions in PRD resolved (no `blocker` open).
-- [ ] Trigger map covers every PRD goal.
-
-### UX
-- [ ] Every In-scope item has at least one screen spec.
-- [ ] UX design index maps every screen → scenario → AC.
-- [ ] Design system tokens + components needed by the UX exist.
-
-### Strategy
-- [ ] Tech vision `status: aligned`.
-- [ ] NFR principles `status: aligned`; verifiers named for every non-negotiable.
-
-### Architecture
-- [ ] Architecture doc `status: ready-for-stories`.
-- [ ] ADRs cover every meaningful trade-off.
-- [ ] NFR check section answers *how* for each non-negotiable.
-
-### Stories
-- [ ] Every epic has 3–10 stories.
-- [ ] Every story has AC IDs from the PRD; the union per epic equals the epic's AC set.
-- [ ] No story is XL.
-- [ ] Each story names touch-points + `testid` + reuse of design-system components.
-
-### TEA
-- [ ] `tea-risk.md` exists.
-- [ ] `.wize/config/tea.toml` policy is committed (advisory / enforcing).
-- [ ] First-story `tea-design.md` is drafted (proof Hawkeye's contract works).
+**Goal.** Before any story enters dev, confirm everything is in place.
 
-### Cross-cutting
-- [ ] CI runs tests + validators on every PR.
-- [ ] Lint/format on commit.
-- [ ] Branch protection on `main`.
-- [ ] Secrets vault wired; no secret in repo.
+## Checklist
+- [ ] Architecture doc exists and is signed (Tony + Fury approved).
+- [ ] All in-scope screens have UX specs (Mantis).
+- [ ] Design system tokens exist (Mantis).
+- [ ] Stories are sliced with ACs (Tony).
+- [ ] Hawkeye risk profile exists.
+- [ ] `.wize/config/tea.toml` policy choice is recorded.
 
 ## Outcome
-
-- **Ready** → write the readiness file, link from `sprint-planning`.
-- **Concerns** → list specifically what's missing, owner per item, deadline. Re-check.
-
-## Output template
-
-```markdown
----
-status: ready | concerns
-date: YYYY-MM-DD
-chair: Tony Stark
-signoffs:
-  - Maria Hill (PM)
-  - Hawkeye (TEA)
-  - Mantis (UX) — async
-  - Fury (Strategy) — async
----
-
-# Implementation Readiness — {{project_name}}
-
-## Result: Ready
-
-## Notes
-- Architecture covers 5 epics and 28 stories.
-- TEA policy: advisory; NFR gate per epic.
-- 2 ADRs accepted in this gate review (ADR-008, ADR-009).
-
-## Open items (carry forward, not blockers)
-- Marketing site for launch — separate track, owned by …
-- Stripe-Atlas back-office decision — by date X.
-```
-
-## Anti-patterns
-
-- "Looks ready" without running the checklist.
-- Signing off before Hawkeye has risk-profiled.
-- Closing concerns without re-checking.
-- Leaving CI configuration "for later" — never gets done.
-
-## Hand-off
-
-> Implementation readiness signed off. Hill, kick `wize-sprint-planning`. Hawkeye, your gate cadence is set: design per story, trace + review + gate per story, NFR per epic.
+Either `ready: true` or list of fix-asks.