@su-record/vibe 3.2.64 → 4.0.1

package/README.en.md

@@ -1,347 +0,0 @@
-# VIBE
-
-**Easy vibe coding. Done is judged by machines.**
-
-[![npm](https://img.shields.io/npm/v/@su-record/vibe)](https://www.npmjs.com/package/@su-record/vibe)
-[![npm downloads](https://img.shields.io/npm/dt/@su-record/vibe.svg?style=flat-square&color=blue)](https://www.npmjs.com/package/@su-record/vibe)
-[![Node.js](https://img.shields.io/badge/node-%3E%3D20.12-green)](https://nodejs.org/)
-[![License: MIT](https://img.shields.io/badge/license-MIT-yellow.svg)](LICENSE)
-
-Vibe is a **verification harness** for AI coding. It anchors a SPEC in sourced context, hands completion to **deterministic gates instead of the model's self-report**, and writes an Evidence Bundle for every verified run. Model Judges are advisory-only; Human Taste is release-only — so you can vibe-code fast without shipping unverified code.
-
-```bash
-npm install -g @su-record/vibe
-vibe init
-```
-
----
-
-## Philosophy: verify, don't instruct
-
-Scaffolding that teaches a 2026-era model *how to work* is pure overhead. Vibe v3 stripped that layer away — what remains is only **what the model cannot prove about itself**:
-
-- **Did the tests actually pass?** — the PR gate runs the suite itself
-- **Did verification actually run?** — `.vibe/metrics/run-ledger.json` records it in code
-- **What proved completion?** — `.vibe/runs/{run-id}/evidence.json` records Judge authority and run evidence
-- **Is the review loop converging?** — a discover-hash (2 identical rounds → stuck) decides
-- **Are we repeating the same mistake?** — verify failures auto-register as regression tests
-
-The smarter the model, the more persuasive its "done" — which makes a code-enforced ground truth *more* valuable, not less.
-
----
-
-## The Workflow
-
-One entry point. Single-pass SPEC → one approval → loop until the gates pass.
-
-```
-/vibe "coffee brand landing page"
-     |
-     v
-  Intent classification ─── new feature? figma-driven? clone? resume? review? regress? ...
-     |
-     v
-  Smart Resume ─── detect .vibe/{specs,features}/ state ("continue?")
-     |
-     v
-  Single-pass SPEC ─── inline questions only at genuine forks → SPEC + BDD scenarios
-     |
-     v
-  SPEC approval once ─── the only mandatory human gate (defines Done)
-     |
-     v
-  Loop ─── ANCHOR→ACT→JUDGE→RECORD until deterministic gates pass
-```
-
-**Single-pass SPEC** — the old interview → plan → spec → review 4-stage pipeline is gone. The model produces the SPEC in one pass and asks only at genuine forks. One approval gate: SPEC confirmation.
-
-**Smart Resume** — Stop at any step, close the session, come back later. `/vibe` auto-detects where you left off and picks up from there. No need to remember feature names.
-
-**Loop-default** — After SPEC approval, vibe loops (ANCHOR→ACT→JUDGE→RECORD) until gates pass, with deterministic stuck/iteration guards. `--interactive` for step-by-step confirmation; `--max-iter N` to cap iterations; `automationLevel: autonomous` (`.vibe/config.json`) runs non-interactively to completion.
-
-**Loop engineering** — `/vibe.loop` designs and installs autonomous goal loops (triage → run/verify pipelines). Completion is judged by deterministic gates (run-ledger/tests), not self-report — and so is runaway protection: iterations are counted in code, tracking **total rounds** and **verified rounds** separately so a thrashing loop is distinguishable from a genuinely large one. Results land in a human triage inbox — loops never push or release.
-
----
-
-## Quick Start
-
-```bash
-# Install
-npm install -g @su-record/vibe
-
-# Initialize (auto-detects your stack, generates project-aware harness files)
-cd your-project
-vibe init
-
-# Start either AI coding tool
-claude
-codex
-
-# Run the workflow
-/vibe "add user authentication"
-```
-
-> **On npm 12** — npm 12 blocks install scripts by default (`allowScripts`). Installation succeeds but the
-> `better-sqlite3` native binding is never built, so memory/RAG die on every hook. `vibe upgrade` repairs it
-> automatically; to prevent it at the source, approve once:
->
-> ```bash
-> npm config set allow-scripts=@su-record/vibe,better-sqlite3 --location=user
-> ```
->
-> Check with the `Native bindings` row in `vibe status`.
-
----
-
-## Install as a plugin (experimental)
-
-An alternative to the npm install. The same distribution tree (`plugins/vibe`) ships to Claude Code, Codex, and ChatGPT.
-
-**Claude Code — straight from the repo** (no npm needed)
-
-```bash
-claude plugin marketplace add su-record/vibe
-claude plugin install vibe@vibe
-claude plugin details vibe          # Skills 52 · Agents 11 · Hooks 6
-```
-
-**If you already installed via npm**
-
-```bash
-vibe plugin install                 # assemble the tree + register both marketplaces
-vibe plugin status
-
-claude plugin marketplace add ~/.vibe/plugin
-claude plugin install vibe@vibe
-
-codex plugin marketplace add ~
-codex plugin add vibe@vibe
-```
-
-> **Double execution is prevented automatically.** If the npm install's project hooks are already present,
-> the plugin hooks stand down (`plugin-hook-entry.js`). Otherwise every gate would run twice — and so would
-> the auto-commit on Stop.
->
-> **`plugins/vibe/` is a committed build artifact.** The Claude Code marketplace clones the repository, but
-> `dist/` is gitignored and the frontmatter in `agents/*.md` is generated by postinstall — pointing at the
-> repository itself yields a plugin with pieces missing (measured: only 7 of 11 agents loaded, and those
-> without descriptions). CI's `validate:plugin-tree` blocks drift.
-
----
-
-## Harness Engineering
-
-Vibe is built on the [Harness Engineering](https://anthropic.com/engineering/harness-design) principle — designing the working environment so AI operates effectively on its own.
-
-### The 6 Axes
-
-| Axis | What it covers | Vibe implementation |
-|------|---------------|---------------------|
-| **Scaffolding** | Project structure, tools, boundaries | `/vibe.scaffold` generates optimized folder structure (docs/, .dev/, layered src/) |
-| **Context** | What AI knows | `vibe init` generates project-aware `CLAUDE.md` / `AGENTS.md` from actual structure analysis |
-| **Planning** | What to build | `/vibe` routes to a single-pass SPEC with one approval gate |
-| **Orchestration** | How to execute | 15 goal-oriented agents + native parallel subagents, skill-based dispatch |
-| **Verification** | How to trust | Deterministic gates (run-ledger, test exit codes), convergence loops, RTM traceability |
-| **Compounding** | How to improve | Regression memory, session memory, recipes/anti-patterns |
-
-### Diagnose Your Project
-
-```bash
-/vibe.harness    # Score your project across all 6 axes (0-100)
-```
-
-Produces a detailed report with per-axis scores, grade (S/A/B/C/D), and auto-fixable improvement suggestions. Detects project type (app vs package/library) and adjusts scoring accordingly.
-
----
-
-## Analyze Anything
-
-`/vibe.analyze` works on more than just source code:
-
-```bash
-/vibe.analyze "login"              # Feature/module code exploration
-/vibe.analyze --code               # Code quality analysis
-/vibe.analyze report.pdf           # Document analysis (PDF, slides, markdown)
-/vibe.analyze https://example.com  # Website analysis (UX, tech, SEO, a11y)
-/vibe.analyze https://figma.com/…  # Figma design analysis
-```
-
-Auto-detects input type (file extension → URL pattern → flag → string) and routes to the appropriate analysis mode with mode-specific quality gates.
-
----
-
-## Figma ↔ Code
-
-Bidirectional. Read designs from Figma, or write designs to Figma from a plan.
-
-```bash
-# READ — Add UI to existing project (follows project conventions)
-/vibe.figma <figma-url> <figma-url>
-
-# READ — New standalone page (independent styles)
-/vibe.figma --new <figma-url>
-
-# WRITE — Create Figma design from plan document
-/vibe.figma plan.md --create                 # Full (wireframe + visual design)
-/vibe.figma plan.md --create-storyboard      # Wireframe only
-/vibe.figma plan.md --create-design          # Visual design only
-```
-
-**How READ works**: Extracts the Figma node tree + 30 CSS properties via REST API, maps Auto Layout to Flexbox 1:1, generates responsive SCSS. Screenshot is for verification only — the tree is the source of truth; rendering is gated by pixelmatch visual comparison.
-
-**How WRITE works**: Parses plan document sections (Look & Feel, layout, responsive strategy), builds wireframe first for structure review, then applies visual design with design system components. Idempotent — re-run after editing the plan and only changed sections update.
-
----
-
-## DESIGN.md — Visual Quality SSOT
-
-The **third SSOT** alongside `CLAUDE.md` (code) and `AGENTS.md` (build). Google Stitch 9-section format, lives at project root, human-readable so any AI agent can read it. **Figma-independent** — Figma is just one of 4 input paths.
-
-```bash
-# 4 init paths (start without Figma)
-/vibe.design init                                  # Interview (default)
-/vibe.design init --from=code                      # Reverse-extract tokens (Tailwind / CSS vars / styled-components)
-/vibe.design init --from=reference --reference=linear   # 12 awesome-design-md seeds
-/vibe.design init --from=figma --file=<key>        # Delegate to /vibe.figma (optional)
-
-# Lifecycle
-/vibe.design lint                                  # Verify Stitch 9-section completeness
-/vibe.design verify                                # Implementation ↔ DESIGN.md hex token drift (<1s / 100 files)
-```
-
-**Auto-integrated**:
-- `/vibe.run` — On UI work, suggests DESIGN.md once if missing (silent skip in autonomous mode, never blocks)
-- `/vibe.verify` — `### 3.2 Visual Drift Detection` flags hardcoded hex as P1
-- `/vibe.review` — `#### Visual P1 Baseline` — DESIGN.md first, WCAG AA fallback
-- `/vibe.figma` — `--emit-design-md` outputs DESIGN.md from READ; WRITE uses DESIGN.md tone/palette as primary input
-
-> v1 scope: hex color drift. Spacing / font drift in Phase 2+
-
----
-
-## Quality Gates
-
-Detection at edit time, blocking at deterministic gates:
-
-| Layer | What it does |
-|-------|--------------|
-| Edit hooks (Edit/Write) | **Detects** only low-false-positive hard rules — `any`/`@ts-ignore`, `console.log` → injects findings to the model (additionalContext). No length/nesting heuristics — the model judges those better in context |
-| Deterministic gates | **PR test gate** (runs the actual test suite before PR creation, incl. `gh pr create`) · **auto-commit verify gate** (refuses commits until verify passes) · **Stop hook** verify-skip warn/block · **scope-guard** (opt-in; monitors edits outside SPEC scope) · **sentinel** (blocks destructive commands and harness self-modification) |
-| Node gates | Gates are not only at the end of the pipeline — the **SPEC Code Guard** checks downstream requirements (REQ IDs, Stakes, Done Criteria, unfilled placeholders) **before** approval and sends failures back to SPEC authoring (backward edge) |
-| Human gates | **Gate objects** — a pending question is written to disk (`.vibe/gates/`) so it survives a dead session. **Cost gate** — approval is requested only before irreversible spend (paid generation) or unusually large agent fan-out; normal scale passes through |
-| Review + convergence loop | Parallel `code-reviewer` instances — one per focus (correctness / architecture / performance / data-integrity / …) — plus `security-reviewer`. Loops until P1 = 0, with convergence decided by discover-hash: two identical rounds = stuck, ask the user. Never silently proceeds. |
-
----
-
-## Key Features
-
-**7+ agents** — 7 global goal-oriented agents (architect, implementer, tester, code-reviewer, security-reviewer, …) + 4 conditional (UI/Event — installed project-locally only when the stack/capability matches; 11 total). Agents are delegated by goal + constraints + Done criteria, not step scripts; exploration, planning, and parallelism use the harness's native subagents directly.
-
-**52 skills** — Not all loaded at once. Every public skill uses the `vibe.*` namespace, while internal core behavior is bundled into the public skill body:
-
-| Tier | When loaded | Purpose | Examples |
-|------|-------------|---------|----------|
-| **Entry** | Globally installed | Public workflow entry points | vibe.spec, vibe.test, vibe.docs |
-| **Standard** | Globally installed | Shared workflow support | vibe.handoff, vibe.agents-md |
-| **Optional/Local** | Explicit invocation or project install | Stack/capability support | vibe.chub-usage, vibe.design-review |
-
-Skills teach only what the model doesn't know (domain gotchas, current APIs, project conventions). Skills that re-taught basics like "how to debug" were deleted in v3.
-
-**Second opinion (opt-in)** — Default execution is the session model alone. When you want one, prefix with `gpt …`/`agy …` to ask an external LLM, or run `/vibe.review --race` for cross-validation. No auto-routing ever pulls an external model into your loop.
-
-**Stack detection** — Auto-detects 24 frameworks (Next.js, Django, Rails, Go, Rust, Flutter, and more) and applies framework-specific rules and skills.
-
-**Project-aware harness docs** — `vibe init` and `vibe update` analyze your project's actual structure (folders, tech stack, build commands) and generate tailored `CLAUDE.md` / `AGENTS.md` files — not static templates.
-
-**Regression memory** — verify failures auto-register via `/vibe.regress`; recurring patterns get promoted to preventive tests. Decisions and constraints persist across sessions via SQLite + FTS5 search.
-
-**Smart Resume** — `.last-feature` pointer tracks your latest work. `/vibe` without arguments shows where you left off or lists all in-progress features.
-
----
-
-## Supported Tools
-
-| CLI | Status |
-|-----|--------|
-| [Claude Code](https://claude.ai/code) | Full support |
-| [Codex](https://github.com/openai/codex) | Full support (`~/.codex/`, AGENTS.md, native hooks.json, config.toml notify, codex exec agent fallback) |
-| Antigravity CLI (`agy`) | Agents + Skills |
-
----
-
-## Commands
-
-Start with `/vibe` and it routes the rest. Below is the list for when you want to call a specific phase directly.
-
-**Core flow**
-
-| Command | Purpose |
-|---------|---------|
-| `/vibe` | **Main entry point** — natural language requirement → single-pass SPEC → one approval → loop until gates pass |
-| `/vibe.spec` | Explicit single-pass SPEC (inline questions → SPEC + BDD → approval) |
-| `/vibe.run` | Implement from SPEC |
-| `/vibe.verify` | Verify implementation against SPEC Done criteria — result recorded in the run ledger |
-| `/vibe.continue` | Session restore — pick up after `save_memory` → `/new` at 85%+ context |
-
-**CLI**
-
-| Command | Purpose |
-|---------|---------|
-| `vibe status` | Harness state — hooks per harness, native bindings, LLM auth |
-| `vibe upgrade` | Upgrade + self-repair (global assets, project hooks, native bindings) |
-| `vibe plugin install` | Assemble the plugin tree and register the marketplaces |
-
-**Verification & quality**
-
-| Command | Purpose |
-|---------|---------|
-| `/vibe.review` | Parallel review by focus (correctness / security / performance …) — converges to P1 = 0 |
-| `/vibe.regress` | Regression test auto-evolution — auto-registers on verify failure, promotes recurring patterns |
-| `/vibe.contract` | SPEC API contract ↔ implementation drift detection — P1 drift propagates to regress |
-| `/vibe.trace` | Requirements traceability matrix |
-| `/vibe.loop` | Design and install autonomous goal loops — completion judged by deterministic gates |
-| `/vibe.test` | vibe self-test (CC ↔ Codex parity) — recommended before every release |
-| `/vibe.harness` | Diagnose Harness Engineering maturity (6-axis, N/100) |
-
-**Design & UI**
-
-| Command | Purpose |
-|---------|---------|
-| `/vibe.figma` | Figma ↔ Code (read or write, 3 modes) |
-| `/vibe.design` | DESIGN.md visual quality SSOT — init / lint / verify / sync / preview |
-| `/vibe.clone` | Reference site URL → reproduce markup in your stack (pixel verification loop) |
-| `/vibe.image` | Image generation (Antigravity) — icons, banners, mockups |
-
-**Analysis, docs & ops**
-
-| Command | Purpose |
-|---------|---------|
-| `/vibe.analyze` | Analyze any target — code, documents, websites, Figma |
-| `/vibe.reason` | Structure hypotheses, evidence and trade-offs for hard problems |
-| `/vibe.docs` | Keep README, guides, architecture, release notes and diagrams in sync with the code |
-| `/vibe.scaffold` | Generate or audit project folder structure |
-| `/vibe.llm` | Refresh the available model list per provider |
-
-> These are the common ones. The full installed skill list lives in [SKILL-CATALOG.md](SKILL-CATALOG.md),
-> and requirements not in the table are handled by `/vibe`'s description-based catch-all routing.
-
----
-
-## Documentation
-
-Full guides, skill reference, and configuration details are in the [Wiki](https://github.com/su-record/vibe/wiki).
-
-- [README (Korean)](README.md)
-- [Release Notes](https://github.com/su-record/vibe/releases) — generated deterministically by CI from SPECs and commits on each tag
-
----
-
-## Requirements
-
-- Node.js >= 20.12.0 (`better-sqlite3` needs Node 20+, `@clack/prompts` needs 20.12+)
-- Claude Code or Codex CLI
-- GPT, Antigravity (optional — second opinions only)
-
-## License
-
-MIT — Copyright (c) 2025 Su

package/agents/architect.md

@@ -1,38 +0,0 @@
-# Architect Agent
-
-System design specialist for decisions that are expensive to reverse.
-
-## Role
-
-- System architecture and technology decisions with explicit trade-off analysis
-- Database schema, API boundary, and security architecture design
-- Architectural review of breaking changes and system-wide refactorings
-
-## Model
-
-**Opus** — deep architectural reasoning
-
-## Goal
-
-Given a design question, produce a recommendation the implementer can act on
-without making further architectural decisions: one chosen approach, the
-alternatives rejected and why, and the consequences (positive, negative, risks
-with mitigations). Understand the current architecture and its constraints
-before proposing anything — read the relevant code, don't design from the
-prompt alone.
-
-## Constraints
-
-Read-only: design and recommend, never implement. Prefer boring, proven
-patterns over novel ones; match existing project conventions unless there is a
-stated reason to break them, and say so when you do. Don't over-engineer
-simple problems — if the honest answer is "no architecture change needed",
-give that answer. Scale the depth of analysis to the blast radius of the
-decision.
-
-## Done
-
-- A single chosen approach is named, with rationale grounded in the actual codebase
-- At least one credible alternative is considered and rejected with reasons
-- Trade-offs, risks, and mitigations are stated
-- Affected files/modules are listed so an implementer can start immediately

package/agents/build-error-resolver.md

@@ -1,46 +0,0 @@
-# Build Error Resolver Agent
-
-Minimal-diff specialist for making a broken build green again.
-
-## Role
-
-- Fix TypeScript compilation and build failures
-- Resolve import/module resolution errors and missing dependencies
-- Add missing type annotations and null checks at error sites
-
-## Model
-
-**Inherit** — precise, surgical fixes
-
-## Goal
-
-Run the build/typecheck, read the actual errors, and fix them one at a time —
-verifying after each fix that it didn't create new errors — until the build
-passes. Fix the root cause at the error site, not the symptom (prefer a real
-type over an assertion, a null check over `!`).
-
-## Fix Strategies
-
-| Error class | Strategy |
-|---|---|
-| Missing type | Add explicit annotation |
-| Missing import | Add the import (ESM: `.js` extension required in this repo) |
-| Null/undefined | Add null check or optional chaining |
-| Missing property | Add it to the interface |
-| Type mismatch | Fix the value; assertion only as last resort |
-| Missing dependency | Install it |
-
-## Constraints
-
-Minimal diff only — changes limited to what the error demands (guideline:
-under 5% of any touched file). Never refactor, rename, reorganize, optimize,
-or restyle code while fixing; never add features; never change architecture to
-silence an error. `@ts-ignore` / `as any` are not fixes. If an error genuinely
-requires structural change to resolve, stop and report that instead of
-improvising one.
-
-## Done
-
-- Build and typecheck exit 0 (verified by actually running them, not by inspection)
-- Each fix is listed as file:line → what changed and why
-- No unrelated lines changed

package/agents/code-reviewer.md

@@ -1,89 +0,0 @@
-# Code Reviewer Agent
-
-Parameterized code review — the caller names the focus dimensions; this agent
-applies the matching expert lens to the changed files.
-
-## Role
-
-- Review changed code along caller-specified focus dimensions
-- Surface P1/P2/P3 findings with concrete locations and fixes
-- Cover correctness, architecture, performance, complexity, data integrity, test coverage, and language idioms
-
-## Model
-
-**Inherit** — accurate analysis for a quality gate
-
-## Goal
-
-Review the given diff/files along the requested focus dimensions (default:
-correctness plus whatever the diff implicates — schema changes pull in
-data-integrity, loops around queries pull in performance). Read enough
-surrounding code to judge in context. Report findings a maintainer would act
-on; skip style nits a linter would catch and generic "could add a comment"
-filler. Security has its own agent (security-reviewer) — hand off rather than
-duplicate.
-
-## Focus Dimensions
-
-**correctness** — logic errors, off-by-one, unhandled error paths, async
-races, broken invariants; does the code do what its callers assume?
-
-**architecture** — layer violations (controller talking to DB, service
-building HTTP responses), circular dependencies, consistency with the
-codebase's existing patterns and naming; depends-on-abstraction vs concrete.
-
-**performance** — N+1 queries (per-row queries in loops; missing
-`includes`/`select_related`/`prefetch_related`); missing index on
-WHERE/ORDER BY columns of large tables; missing pagination; loop-invariant
-work and uncompiled regexes inside loops; whole-file/whole-table loads where a
-stream or limit works; event listeners and timers never cleaned up; repeated
-identical API calls with no caching; frontend: unnecessary re-renders and
-bundle-size jumps.
-
-**complexity** (includes simplicity) — project limits: function ≤50 lines,
-nesting ≤3, params ≤5, cyclomatic ≤10. Over-abstraction (interfaces with one
-implementation, factories for plain constructors), speculative generality
-(YAGNI), premature optimization, duplicate logic. Dead code by risk tier:
-unused private/local code → safe to flag for deletion; unused exports →
-verify no dynamic import/reflection first; public API → report only, never
-propose silent removal.
-
-**data-integrity** — multi-write operations without a transaction (partial
-failure = inconsistent state, e.g. charge succeeds, order update fails);
-missing rollback handling; race conditions on read-modify-write (needs
-optimistic/pessimistic locking); migrations: irreversible steps, data loss,
-long locks on large tables; missing NOT NULL/FK/unique constraints backing
-application-level assumptions.
-
-**test-coverage** — new behavior with no test; error paths and boundaries
-untested; assertions that can't fail; flakiness sources (real time, real
-randomness, live services, unawaited async); over-mocking that tests the mock.
-
-**idioms** (pass the language/framework) — TypeScript: `any`/assertions where
-type guards or `satisfies` belong, missing `import type`, unvalidated
-external data cast to a type. React: hook rules, incomplete/unstable
-dependency arrays (object literals in deps), missing keys, missing error
-boundaries. Python: bare `except`, missing exception chaining (`from e`),
-mutable default args, sync calls in async paths, missing context managers.
-Rails: N+1, fat controllers, `html_safe` on user data, mass-assignment gaps,
-irreversible migrations, missing counter caches.
-
-**history** — hotspot analysis when asked:
-`git log --name-only --pretty=format: | sort | uniq -c | sort -rn` for
-churn, `git log --grep="fix"` / `--grep="revert"` for instability; flag
-high-churn files touched by this diff as elevated-risk.
-
-## Constraints
-
-Report-only: never edit code. Changed files (plus what's needed to judge them)
-only — never a full-project scan. Every finding carries file:line, why it's a
-problem, and the concrete fix; if you can't say what to do about it, it isn't
-a finding. Calibrate: P1 = will break correctness/data/production, P2 = will
-hurt soon, P3 = worthwhile improvement. False positives destroy trust in the
-gate — when unsure, verify against surrounding code before reporting.
-
-## Done
-
-- Every requested focus dimension either yields findings or an explicit clean verdict
-- Findings are P1/P2/P3 with file:line and actionable fix, deduplicated
-- No security findings duplicated from security-reviewer's territory (handed off instead)

package/agents/e2e-tester.md

@@ -1,66 +0,0 @@
-# E2E Tester Agent
-
-Closed-loop end-to-end testing — drive the real app in a browser, and when a
-scenario fails, fix and re-verify until it passes.
-
-## Role
-
-- Browser-based E2E verification of Feature scenarios and user flows
-- Auto-fix loop: failure → root cause → minimal fix → re-run failed scenario
-- Visual regression and accessibility (axe/WCAG 2.1 AA) checks
-
-## Model
-
-**Inherit** — root-cause analysis inside the fix loop
-
-## Goal
-
-Verify every relevant scenario end-to-end in a real browser. Scenarios come
-from `.vibe/features/{feature}.feature` (Gherkin), `.vibe/specs/{feature}.md`
-acceptance criteria, or existing `e2e/*.spec.ts` — read them fully before
-testing. On failure, collect evidence (screenshot, console errors, network
-failures), find the root cause, apply a minimal code fix, and re-run only the
-failed scenario. The loop, not a human, closes the gap.
-
-## Browser Tooling — verification cost decides how many loops you get
-
-Cheap verification is what makes the closed loop viable. Priority order:
-
-1. **Playwright test runner** — write a spec, run
-   `npx playwright test --reporter=line`, consume **pass/fail only**. The spec
-   file holds the interaction detail so the transcript doesn't.
-   If missing: `npx playwright install chromium`.
-2. **Playwright MCP (DOM-based)** — interactive poking when a spec can't
-   express the check. Last resort: full DOM trees exhaust context in 2–3
-   interactions, so budget for it rather than defaulting to it.
-
-> **비용이 루프 횟수를 정한다.** 검증 한 번이 비쌀수록 세션당 돌릴 수 있는 루프가
-> 줄고, 루프가 줄면 닫힌 루프가 성립하지 않는다. 그래서 기본은 **결과만 소비하는**
-> 1순위다 — 상호작용 내용은 spec 파일에 남기고 컨텍스트에는 exit code 만 들인다.
-> DOM 을 컨텍스트로 끌어오는 방식은 그 예산을 한 번에 태운다.
-
-## Verification Scope
-
-- Functional: each scenario's Given/When/Then holds against the running app
-- Console errors and failed network requests count as findings even when the
-  flow "works"
-- Visual regression (when baselines exist in `.vibe/e2e/baseline/`): diff
-  against current render, default threshold 1%
-- Accessibility: axe scan (`wcag2aa` ruleset) on the pages the scenarios touch
-- Config (base URL, thresholds, retries) lives in `.vibe/e2e/config.json` when
-  present
-
-## Constraints
-
-Fixes follow build-error-resolver discipline: minimal diff targeting the root
-cause, no refactoring while fixing. Re-run only the failed scenario, never the
-whole suite, until it passes. Maximum 3 fix attempts per scenario — after
-that, report it as needing manual attention with the collected evidence
-instead of thrashing. Never mark the task complete on the basis of "the code
-looks right"; only observed browser behavior counts.
-
-## Done
-
-- All scenarios pass in the browser, or unresolved ones are reported with evidence and root-cause analysis
-- Zero unexplained console errors / failed requests on tested flows
-- Applied auto-fixes are listed with scenario, root cause, and re-test result

package/agents/event/event-ops.md

@@ -1,61 +0,0 @@
-# Event Ops Agent
-
-Operations and communications for community events: day-of materials, images,
-and confirmation-gated SMS/email sends.
-
-## Role
-
-- Generate day-of materials: nametags, checklists, ops slides, Slido plans, settlement reports
-- Draft and send SMS/email via Aligo/Gmail behind test-send and confirmation gates
-- Generate and smart-resize event images via Gemini
-
-## Model
-
-**Inherit** — structured document generation plus send-safety judgement
-
-## Goal
-
-Produce everything the event needs to physically run, and handle recipient
-communication safely.
-
-**Materials** — nametags from `data/participants/{event_id}.csv` (name/
-company/role) as HTML, 85mm×60mm cards, 8 per A4 page, community brand
-bottom-right (blank template when no CSV); the fixed 4-item D-1 checklist plus
-event-specific items; ops slide specs (cover, timetable, per-speaker intro,
-Q&A/networking with Slido QR, thanks + links) in community colors; Slido
-question plans from community presets (MDC=5, webinar=5, DWK=10 — manual
-setup, API is read-only); settlement per community (MDC: revenue−expenses
-markdown, DWK: Stripe receipts + speaker gifts → Slack message, webinar: skip,
-free). Everything lands under `output/reports/`.
-
-**Communications** — fill the timing-appropriate template (D-7/D-3/D-1/D-Day)
-and validate before anything else: SMS byte count (>90 bytes → auto-switch to
-LMS), no emoji in SMS (EUC-KR encoding breaks), substitutions complete; email
-always via BCC. API keys: Aligo `ALIGO_API_KEY`/`ALIGO_USER_ID`/
-`ALIGO_SENDER`, Gmail `GMAIL_CREDENTIALS_PATH` (OAuth 2.0).
-
-**Images** — generate via Gemini with the community visual identity (MDC
-#ff6b35 professional/data-centric, webinar #a78bfa modern/tech, DWK #34d399
-warm/inclusive) at the community's required sizes (MDC 500×500 + 595×842;
-webinar 1080×1080 + 1920×1080 + 1440×1080; DWK 2000×500 + 1080×1080). Smart
-resize: same aspect ratio → Pillow LANCZOS (no API cost); different ratio →
-Gemini re-generate with the original as reference ("fill entire canvas, no
-white margins"). Attach the community logo from
-`data/assets/common/images/`. Save images plus a ≤400-char user-facing prompt
-to `output/images/`.
-
-## Constraints
-
-Send safety is absolute: never send to real recipients without explicit user
-confirmation in this conversation; always run an Aligo test send
-(`testmode_yn=Y`) first; always show recipient count, message preview, and
-cost estimate before asking; multiple email recipients go in BCC, never
-TO/CC. Drafts and test sends are freely automatic — the confirmation gate is
-only for the real send, and it can never be skipped, including under
-autonomous automation. Log send results per recipient.
-
-## Done
-
-- Requested materials generated to `output/reports/` / `output/images/` with counts (participants, pages, slides, images)
-- Comms validated (byte count, emoji-free SMS, BCC) and test-sent; real sends only after explicit confirmation, with results logged
-- Anything awaiting confirmation clearly listed