wize-dev-kit 0.14.0 → 0.16.0

package/src/orchestrator-skills/wize-orchestrator/persona.md

@@ -7,27 +7,9 @@ I am **Wizer**. I am the host of this development kit. I know who you are, what
 ## Operating principles
 
 1. **Listen first.** Before routing, I make sure I understand the demand. One clarifying question is cheaper than three wrong hand-offs.
-2. **Route by intent, not just phase.** When the user's message contains a clear intent phrase ("quero pesquisar concorrência", "cria um PRD", "roda um pentest"), I route directly to the matching skill using the intent routing table. I use the phase heuristic only when intent is ambiguous or no intent phrase matches.
-3. **Route, don't perform.** I rarely do the specialist's job. When the question is a brief, I call Pepper. When it is a PRD, Maria Hill. When it is architecture, Tony.
-4. **Keep the thread.** I keep the knowledge of the project consistent across conversations. If something changed, I update `.wize/config/project.toml` before moving on.
-5. **Pair when needed.** When a decision crosses concerns (UX touching architecture, PM touching TEA), I open a **party-mode** with the relevant agents.
-6. **Treat the kit as the contract.** `.wize/`, `AGENTS.md`, and the installed `wize-*` skills are the operating instructions and persistent memory of whoever executes — not background reading. I make sure a demand is classified (Quick Dev vs Full Lifecycle, via `/wize` or `/wize-help`) and framed as a mission — objective, sources of truth, scope, acceptance criteria, validation — before any code is touched.
-7. **Harness-aware interaction.** In text-only harnesses, I ask one clarifying question when intent is ambiguous. In rich-UI harnesses, I offer a menu of matching options.
-
-## Fan-out to subagents
-
-Party-mode is personas taking turns in this same thread — for live back-and-forth. When a step instead needs several **independent** reads on the same input (adversarial review, edge-case sweep, N-way research) that shouldn't see each other's output, I don't fake it by looping through personas myself. Any skill that needs this follows the same pattern:
-
-1. **Name each subagent's role and prompt.** E.g. "Blind Hunter — reviews the diff cynically."
-2. **Scope its context explicitly.** State exactly what it can see (diff only? diff + repo read access? diff + spec?). The isolation is the point — a subagent that sees everything can't give an independent read.
-3. **Dispatch on whatever the current harness natively supports:**
-   - Claude Code — the Task/Agent tool, one call per subagent, run concurrently.
-   - OpenCode — the persona files this kit renders under `.opencode/agents/*.md` with `mode: subagent`; invoke by name.
-   - Any harness without a subagent primitive (Codex included) — there is no isolated dispatch available. Generate one prompt file per subagent under the skill's artifact folder and halt, asking the user to run each in a separate session.
-4. **Match the model tier to the task.** Independent reads aren't all equal weight. Dispatch mechanical layers (file sweeps, grep passes, short summaries) on a **lightweight tier**; implementation, refactor, and standard review on the **standard tier**; reserve a **high-capability tier** for architecture calls, critical decisions, and final adversarial review — or when a standard-tier layer already failed. Pass the tier explicitly whenever the harness lets you set it; don't just inherit the session default. Tiers only — never name a vendor's models.
-5. **Tolerate partial failure.** If one subagent fails, times out, or returns empty, note it and proceed with whatever the others returned. Don't block on one flaky layer.
-
-`wize-code-review` is the reference implementation (see its step-02).
+2. **Route, don't perform.** I rarely do the specialist's job. When the question is a brief, I call Pepper. When it is a PRD, Maria Hill. When it is architecture, Tony.
+3. **Keep the thread.** I keep the knowledge of the project consistent across conversations. If something changed, I update `.wize/config/project.toml` before moving on.
+4. **Pair when needed.** When a decision crosses concerns (UX touching architecture, PM touching TEA), I open a **party-mode** with the relevant agents.
 
 ## Voice
 
@@ -41,29 +23,6 @@ Before greeting, read `.wize/config/user.toml` if it exists. If it has `[user] n
 
 If `user.toml` is missing or has no `name`, fall back to a neutral greeting.
 
-## First-run detection
-
-Before greeting, check whether this is a first run:
-
-1. Read `.wize/planning/brief.md` — if it exists, this is NOT a first run.
-2. Read `.wize/knowledge/document-project/` — if it has content (any `.md` files), this is NOT a first run.
-3. If neither exists: **first run**.
-
-## First-run flow
-
-When first run is detected, do NOT show a menu. Ask one question:
-
-> "O que você está construindo?"
-
-Wait for the answer. Then classify:
-
-- **Greenfield** (new project, idea, feature, product): route to **Pepper / `wize-product-brief`**.
-- **Brownfield** (existing codebase, legacy system, "we already have X"): route to **Pepper / `wize-document-project`**.
-
-If the answer is ambiguous, ask one clarifying question: "Is this a new project or an existing codebase?" Then route.
-
-Never show a menu on first run. One question → classify → route.
-
 ## Greet
 
 > "Welcome back{{`, ` + user.name when present, else ''}}. What are we working on?"

package/src/orchestrator-skills/wize-party-mode/workflow.md

@@ -1,7 +1,5 @@
 ---
-
 code: wize-party-mode
-description: "Use quando uma decisão cruzar preocupações de múltiplos agentes e precisar de discussão multi-agente facilitada."
 name: Party Mode (multi-agent)
 owner: wize-orchestrator   # Wizer facilitates
 status: stub

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

@@ -1,132 +1,38 @@
 ---
-
 code: wize-tea-design
-description: "Use quando uma story entrar em desenvolvimento e precisar do contrato de testes (split, fixtures, mocks, assertions) que a Shuri implementará."
 name: TEA Test Design
-phase: 4-implementation
 gate: design
 owner: wize-agent-test-architect   # Hawkeye
 when: per-story-start
-status: ready
+status: stub
 ---
 
 # TEA — Test Design
 
-**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).
+**Goal.** For one story: declare the test split (unit / integration / e2e), required fixtures, mocks, environments.
 
 ## 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`
 
-## 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 frontmatter
 ```yaml
 ---
 gate: design
-story_id: E01-S03
-ac_ids: [AC-02-1, AC-02-2]
-status: PASS
-created_at: 2026-06-11T12:00:00Z
+story_id: …
+ac_ids: [AC-1, AC-2, …]
 test_split:
-  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"
+  unit: count + brief description
+  integration: count + brief description
+  e2e: count + brief description
+fixtures: [...]
+mocks: [...]
+environment: dev|staging|isolated
 ---
 ```
 
-## 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.
+## Body
+Plain-English rationale + edge-case list.

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

@@ -1,144 +1,51 @@
 ---
-
 code: wize-tea-gate
-description: "Use quando uma story chegar ao final e precisar da decisão de gate (PASS/CONCERNS/FAIL/WAIVED) com rationale documentado."
 name: TEA Gate Decision
-phase: 4-implementation
 gate: gate
 owner: wize-agent-test-architect   # Hawkeye
 when: story-final
-status: ready
+status: stub
 ---
 
 # TEA — Gate Decision
 
-**Goal.** Final per-story decision. **PASS / CONCERNS / FAIL / WAIVED** with documented rationale, score, and policy mode. This is the line: a story doesn't advance past it without a recorded gate.
-
-Hawkeye drives. The four inputs (`design`, `trace`, `review`, plus `nfr` at epic boundary) feed in. Policy is read from `.wize/config/tea.toml`.
+**Goal.** Final per-story gate. PASS / CONCERNS / FAIL / WAIVED with documented rationale.
 
 ## Inputs
-
-- `.wize/implementation/tea/{epic}/{story}/design.md`
-- `.wize/implementation/tea/{epic}/{story}/trace.md`
-- `.wize/implementation/tea/{epic}/{story}/review.md`
-- `.wize/implementation/tea/nfr/{epic}.md` (when the story is the last of its epic)
-- `.wize/config/tea.toml`
+- `design.md`, `trace.md`, `review.md` for the story
+- `nfr/{epic}.md` if applicable
+- Story file
 
 ## Output
-
 - `.wize/implementation/tea/{epic}/{story}/gate.md`
 
-## Decision rules
-
-| Inputs | Recommendation |
-|---|---|
-| All ACs `met`, no findings | **PASS** |
-| All ACs `met`, only low/medium non-blocking findings | **PASS** with notes (or **CONCERNS** depending on count) |
-| Any AC `partial` | **CONCERNS** |
-| Any AC `not-met` | **FAIL** |
-| NFR `FAIL` on the epic (last story) | **FAIL** |
-| `tea-review` flagged `knowledge_axes_touched` ≠ `knowledge_axes_updated` (any axis touched without update) | **CONCERNS** (advisory mode) / **FAIL** (enforcing mode) — adds finding `KN-NN` |
-| Failing AC OR non-neg NFR with documented business rationale + senior signoff | **WAIVED** |
-
-Score (0–100): heuristic. `100 - (10 × high) - (5 × medium) - (2 × low)`. Floor 0.
-
-## Policy
-
-`.wize/config/tea.toml` sets `policy = "advisory"` (default) or `"enforcing"`.
-
-- **Advisory:** `FAIL` is a visible warning in PR; merge isn't auto-blocked. The team decides.
-- **Enforcing:** `FAIL` blocks merge via CI status check (`tea-gate`). PASS / CONCERNS allowed through.
-
-## Steps
-
-### 1. Read the three inputs
-
-If trace shows `partial`, you know the recommendation. If review recommends FAIL, you've got your decision. The gate doc just records it.
-
-### 2. Compute score
-
-Don't game it. The score communicates magnitude to humans skimming a backlog.
-
-### 3. Write the doc
-
-Frontmatter is the structured truth. The body is the narrative for humans.
-
-### 4. Notify
-
-Update the PR description with the gate verdict + link to the doc. Maria Hill watches the gate status in `sprint-status.md`.
-
 ## YAML frontmatter (canonical)
-
 ```yaml
 ---
 gate: gate
-story_id: E01-S03
-status: PASS
-score: 95
-policy: advisory
+story_id: …
+status: PASS | CONCERNS | FAIL | WAIVED
+score: 0-100
+policy: advisory | enforcing
 inputs:
-  design: ".wize/implementation/tea/E01-S03/design.md"
-  trace:  ".wize/implementation/tea/E01-S03/trace.md"
-  review: ".wize/implementation/tea/E01-S03/review.md"
-  nfr:    null   # not the last story of E01
+  - design.md: …
+  - trace.md: …
+  - review.md: …
+  - nfr/{epic}.md: …
 findings:
-  - id: REV-01
-    severity: low
-    summary: "Empty-state copy slightly differs from Mantis' spec."
-    recommendation: "Update `<EmptyTeamPanel>` heading in a follow-up."
-  - id: KN-01
-    severity: medium
-    summary: "Story added a new component (`<InviteForm>`) but architecture-snapshot.md was not updated."
-    recommendation: "Add 2 lines to `.wize/knowledge/document-project/architecture-snapshot.md` under a dated bullet referencing the new component + its public testid contract."
-    owner: shuri
-    blocking: false   # advisory mode; would be true under enforcing
-waived_by: null
-waived_reason: null
-created_at: 2026-06-11T20:30:00Z
+  - id: G-1
+    severity: low | medium | high
+    summary: …
+    recommendation: …
+waived_by: null | "wizer"
+waived_reason: null | "…"
+created_at: ISO-8601
 ---
 ```
 
-## Body of `gate.md`
-
-```markdown
-## Verdict
-**PASS** (score 95)
-
-## Why
-- All ACs met with observed evidence.
-- Trace clean; coverage 100% on ACs, partial on edges (E3, E4) — tracked for follow-up.
-- Review found one low-severity copy finding (REV-01).
-- Story is not the last in epic 01; NFR gate runs separately at epic boundary.
-
-## Notes for follow-up
-- Open a tiny story (or include in next sprint planning) to fix REV-01 and close edges E3, E4.
-
-## Trail
-- design.md → 4/1/1 split (unit/integration/e2e) + 4 edges declared.
-- trace.md → all ACs `covered`; E3 `partial`, E4 `missing` (follow-up).
-- review.md → ACs `met`, scope mostly disciplined, copy nit.
-- nfr.md → N/A (mid-epic).
-```
-
-## When to WAIVE
-
-Rare. Examples:
-- A failing E2E that depends on a flaky external sandbox; the production code is unaffected; sign-off by Tony + Hill.
-- A non-negotiable temporarily slipped because of an external integration blocker; we ship with mitigation in place; sign-off by Fury.
-
-A WAIVE always lists:
-- Who waived (`waived_by`).
-- Why (`waived_reason`).
-- The compensating control (a follow-up story, an SLA monitor, a feature flag).
+## Body
+Narrative explanation; structured data is the YAML.
 
-## Anti-patterns Hawkeye rejects
-
-- **Gating without `review.md`.** No review → no gate.
-- **PASS with a `not-met` AC.** Auto-fail.
-- **WAIVED with no `waived_by` field.** Reject.
-- **Scoring jiggered to clear a threshold.** Trust trumps point-scoring; if the count says 70, don't write 91.
-- **Enforcing mode gates without CI check wiring.** Ghost gate; remove or wire it.
-
-## Hand-off
-
-> Gate for E01-S03: **PASS** (score 95). One low-severity finding logged for follow-up. Maria Hill, sprint-status updated; Shuri, ready to start the next story.
+## Policy
+- **advisory** (default): FAIL is a warning. Merge proceeds.
+- **enforcing**: FAIL blocks merge via CI. Configured in `.wize/config/tea.toml`.

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

@@ -1,130 +1,37 @@
 ---
-
 code: wize-tea-nfr
-description: "Use quando um epic estiver próximo do merge e precisar verificar se atende aos princípios de NFR definidos pelo Fury."
 name: TEA NFR Assessment
-phase: 4-implementation
 gate: nfr
 owner: wize-agent-test-architect   # Hawkeye
 when: pre-merge-per-epic
-status: ready
+status: stub
 ---
 
 # TEA — NFR Assessment
 
-**Goal.** Verify that the **epic** as a whole meets Fury's NFR principles: performance, security, reliability, maintainability, accessibility, cost. Story-level gates miss NFRs that emerge only at integration; this gate catches them.
-
-Hawkeye drives. Tony reviews perf + security findings. Fury escalates if a non-negotiable is at risk. Runs **per epic**, just before any of its stories merges.
+**Goal.** Verify the epic meets Fury's NFR principles: performance, security, reliability, maintainability, accessibility, cost.
 
 ## Inputs
-
-- `.wize/planning/nfr-principles.md` (Fury's targets)
+- `.wize/planning/nfr-principles.md`
 - Code from all stories in the epic
-- Telemetry / benchmark output (lighthouse, web-vitals, macrobenchmark, Sentry perf)
-- Overlay perf playbooks: `web-perf-budgets.md`, `mobile-perf-budgets.md`
+- Telemetry/benchmark output
 
 ## Output
-
 - `.wize/implementation/tea/nfr/{epic}.md`
 
-## Steps
-
-### 1. For each category, run the verifier
-
-| Category | Verifier (typical) |
-|---|---|
-| Performance | lighthouse-ci against epic-scope routes; web-vitals beacon delta |
-| Security | `npm audit --omit=dev`; manual OWASP Top 10 walk; secret scan |
-| Reliability | injected-failure tests (`@chaos` tag); retry policy review; idempotency check |
-| Maintainability | coverage delta; cyclomatic complexity delta; lint baseline |
-| Accessibility | axe on every epic-scope route; keyboard walk on critical flows |
-| Cost | cost dashboard delta in the epic window |
-
-### 2. Score each
-
-For each category: `PASS` (meets non-negotiable) / `CONCERNS` (within stretch range; below non-negotiable on a measurable item with mitigation plan) / `FAIL` (non-negotiable missed; no plan) / `WAIVED` (with documented reason + sign-off).
-
-### 3. Findings (one per slip)
-
-If anything failed or concerned, write the finding: what we measured, what was expected, why the slip, what the next step is.
-
-### 4. Hand off
-
-`PASS` → epic can merge. `CONCERNS` (advisory) → flag in PR description. `FAIL` (enforcing) → blocks merge.
-
-## YAML frontmatter (canonical)
-
+## YAML frontmatter
 ```yaml
 ---
 gate: nfr
-epic: 01-onboarding
-status: CONCERNS
+epic: …
+status: PASS | CONCERNS | FAIL | WAIVED
 scores:
-  performance: PASS
-  security: PASS
-  reliability: CONCERNS
-  maintainability: PASS
-  accessibility: PASS
-  cost: PASS
-findings:
-  - id: NFR-01-1
-    category: reliability
-    severity: medium
-    summary: "Outbox retry interval too aggressive for Resend's documented backoff."
-    expected: "Exponential 30s/2m/10m; we set 5s/15s/45s."
-    actual: "Spike in Resend 429s during integration test."
-    recommendation: "Update retry policy in `lib/email/outbox.ts`; capture with `outbox-retry.spec.ts`."
-    owner: shuri
-    blocking: false
-created_at: 2026-06-11T18:00:00Z
+  performance: …
+  security: …
+  reliability: …
+  maintainability: …
+  accessibility: …
+  cost: …
+findings: [...]
 ---
 ```
-
-## Body of `nfr/{epic}.md`
-
-```markdown
-## Summary
-Epic 01 (onboarding) at gate. Performance and a11y pass non-negotiables; reliability has one mid-severity concern around outbox backoff.
-
-## Per category
-
-### Performance — PASS
-- LCP (signup): 1.45s p75 (target ≤ 2.5s).
-- INP (signup): 90ms p75 (target ≤ 200ms).
-- CLS (signup): 0.03 (target ≤ 0.1).
-- LCP (onboarding): 1.7s p75.
-
-### Security — PASS
-- `npm audit` clean (dev advisories noted in `.audit-ignore.md`).
-- OWASP Top 10 walk: no findings.
-- RLS verified on `users`, `teams`, `memberships`.
-
-### Reliability — CONCERNS
-- See NFR-01-1.
-
-### Maintainability — PASS
-- Coverage 84% on logic modules in this epic.
-- No file > 300 LOC introduced.
-
-### Accessibility — PASS
-- axe clean on `/signup`, `/signup/error`, `/onboarding`, `/onboarding/invite-sent`.
-- Keyboard walk: focus order matches visual; modal traps + restores.
-
-### Cost — PASS
-- No cost dashboard change beyond expected (account creation; mailer spend within budget).
-
-## Action items
-- Shuri: PR-XXX fixes NFR-01-1. Re-run NFR after merge.
-- Hawkeye: re-baseline web-vitals after epic ships to prod.
-```
-
-## Anti-patterns Hawkeye rejects
-
-- **Self-reported "looks fine" with no verifier output.** Attach the artifact.
-- **Concerns left for "later."** Either an action item with owner+deadline or it's not a concern.
-- **Waived without sign-off.** WAIVED needs `waived_by: NAME` + reason.
-- **NFR run on stage with synthetic data.** Use realistic distributions whenever possible.
-
-## Hand-off
-
-> NFR gate for Epic 01: **CONCERNS**. PR can proceed if the reliability finding (NFR-01-1) is committed to be addressed in the next sprint. Otherwise hold the merge.