@su-record/vibe 3.2.0 → 3.2.2

package/skills/restraint/SKILL.md

@@ -1,72 +0,0 @@
----
-name: restraint
-user-invocable: false
-invocation: [auto]
-tier: core
-description: "Restraint gate — block premature abstraction and premature optimization. Escalate the YAGNI ladder only on demonstrated need; optimize only on measured evidence. Merges yagni-ladder + rob-pike."
-triggers: [premature optimization, premature abstraction, abstraction layer, helper module, utility class, wrapper class, manager class, config system, cache layer, parallelize, benchmark]
-priority: 60
----
-
-# Restraint — Don't Write It, Don't Tune It (Yet)
-
-Two constraints, one gate:
-
-- **No premature code.** New abstractions must be *pulled* by a demonstrated
-  need, never pushed by "might need it later." Once the code exists, deleting
-  it costs more than never writing it.
-- **No premature optimization.** Performance work must be *pulled* by a
-  measurement, never by a hunch.
-
-## The YAGNI Ladder (code axis)
-
-Satisfy the need at the **highest** rung that covers it; lower rungs are
-blocked while a higher one applies:
-
-1. **Not needed** — the requirement doesn't ask for it → don't build it
-2. **Stdlib / built-ins** already do it (`crypto`, `Intl`, `pathlib`, …)
-3. **Native platform feature** does it (`<input type="date">`, CSS `:has()`, DB constraints)
-4. **Already-installed dependency** covers it — check the lockfile, don't guess
-5. **One line** — a single expression; no new file, no class
-6. **Minimal code** — only now, and nothing for "later"
-
-Tie-break: native beats a one-liner; stdlib beats a dependency. Generalize
-only when a *second* caller exists.
-
-## Pike's Rules (optimization axis)
-
-- You can't tell where a program spends its time — bottlenecks surprise.
-  **Measure; don't guess.**
-- Don't tune until one part *measurably* overwhelms the rest.
-- Fancy algorithms are slow when n is small — and n is usually small.
-  Ask "what's n?" before "what's the Big-O?"
-- Simple algorithms + the right data structures beat clever code. Data dominates.
-
-Optimization is justified only when ALL hold: a measured bottleneck exists →
-it dominates runtime → the fix is the simplest change addressing it → you
-re-measure after.
-
-## Blocked Impulses
-
-| Impulse | Constraint | Counter |
-|---|---|---|
-| helper / utility / wrapper / manager class | rungs 1–5 | a stdlib call or one line usually suffices |
-| config system for one value | rung 1 | a `const` is the config |
-| generic `Processor(strategy, validator…)` | rung 1 | one concrete function until a second caller exists |
-| "add a cache here" / "parallelize this" | measure first | is this path even hot? Often it's I/O |
-| swap in a B-tree / trie / skip list | what's n? | O(n²) with n=100 is microseconds |
-| "this loop looks slow" | measure first | the bottleneck is probably elsewhere |
-
-## Overrides — Restraint Never Erodes These
-
-1. **Security and trust-boundary work are requirements**, not optional
-   complexity. Input validation, auth checks, escaping stay in — "one line"
-   is no excuse to drop them.
-2. **Deliberate simplifications get a comment + upgrade path**, so the next
-   reader sees a *choice*, not an oversight:
-
-   ```ts
-   // Global lock is enough at current throughput.
-   // Switch to per-account locking if write contention shows up.
-   const lock = new Mutex();
-   ```

package/skills/spec/SKILL.md

@@ -1,118 +0,0 @@
----
-name: spec
-description: 단일 패스 SPEC 작성 본체 — 자연어 요구사항(+첨부) → 필요할 때만 인라인 명확화 질문 → .vibe/specs/{feature}.md + .vibe/features/{feature}.feature 를 한 번에 생성 → 1회 셀프 리뷰 → SPEC 승인(유일한 의무 게이트).
-when_to_use: /vibe.spec 진입점 또는 /vibe 파이프라인의 spec 단계에서 호출. 직접 호출 금지 — /vibe.spec 사용.
-user-invocable: false
-tier: core
----
-
-# spec — Single-Pass SPEC
-
-자연어 요구사항 하나를 받아 **한 번의 패스로** 실행 가능한 SPEC을 만든다. 별도의 interview → plan → review 단계는 없다 — 질문이 필요하면 이 패스 안에서 인라인으로 묻고, 리뷰는 셀프 리뷰 1회로 끝낸다. 완성된 SPEC의 승인이 loop-contract 가 정의하는 **유일한 의무적 사람 개입 지점**이다.
-
-> 루프 시맨틱 SSOT: `vibe/rules/loop-contract.md`. SPEC = ANCHOR 아티팩트, Done Criteria = JUDGE 게이트.
-
-## Input
-
-| 입력 | 처리 |
-|---|---|
-| 자연어 요구사항 | 그대로 SPEC 패스의 주 입력 |
-| 📎 첨부 (md/txt/pdf/이미지 등) | Read 도구로 분석 후 요구사항에 병합 |
-| 파일 경로 인자 (PRD 등) | 존재 확인 후 Read — 첨부와 동일 취급 |
-| **레거시 아티팩트** `.vibe/interviews/{feature}.md`, `.vibe/plans/{feature}.md` | 존재하면 **입력 컨텍스트로만** 읽는다. 절대 요구하거나 재생성하지 않는다 — 없어도 정상 경로 |
-
-## Process
-
-### 1. Git branch + pointer
-
-- `git branch --show-current` — `main`/`master` 이면 `git checkout -b feature/{feature-name}` (소문자·하이픈). feature 브랜치면 그대로 진행.
-- feature 이름 확정 즉시 `.vibe/.last-feature` 에 이름 한 줄 기록 (값이 같으면 no-op).
-
-### 2. Project context
-
-- `.vibe/config.json` 읽기 — `references.languages[]` 의 스택 가이드, `stacks` 확인.
-- 기존 코드 파악이 필요하면 네이티브 Explore 서브에이전트에 위임 (main session 에서 프로젝트 파일을 훑지 않는다):
-
-```text
-Task(subagent_type="Explore",
-  prompt="Find existing implementations related to [FEATURE]. Return: tech stack, relevant files, patterns. Under 200 tokens.")
-```
-
-### 3. Clarify — 진짜 모호할 때만
-
-별도 인터뷰 단계가 아니다. 요구사항·첨부·레거시 아티팩트·코드베이스 컨텍스트로 답을 합리적으로 정할 수 있으면 **묻지 않는다**. 다음 조건을 모두 만족할 때만 질문한다:
-
-- 답에 따라 Done Criteria 나 구현 방향이 실제로 갈라진다 (인증 방식, 데이터 모델의 필수 필드, 외부 연동 여부 등)
-- 합리적 기본값을 SPEC 의 Assumptions 로 명시하는 것으로 대체할 수 없다
-
-질문할 때는 **한 번에 묶어서** (번호 목록, 최대 5개), 각 질문에 제안 기본값을 붙인다. `automationLevel: autonomous` 면 질문 없이 기본값을 채택하고 전부 SPEC 의 Assumptions 섹션에 기록한다.
-
-사소한 값(타임아웃, 페이지 크기, 재시도 횟수 등)은 묻지 말고 상식적 기본값을 채택 + Assumptions 에 기록.
-
-### 4. Write SPEC — one pass
-
-`vibe/templates/spec-template.md` 구조로 `.vibe/specs/{feature-name}.md` 를 작성한다. 핵심 요건:
-
-- **Overview / Goal** — 무엇을, 왜. 1-3 문장.
-- **Done Criteria** — 결정론적 게이트만. 각 항목은 "명령/관찰로 pass·fail 판정 가능"해야 한다 (테스트 exit code, 빌드 성공, 특정 동작 관찰). "잘 동작한다" 류 서술 금지 — 이것이 루프의 JUDGE 입력이 된다.
-- **Scenarios** — Given-When-Then. Happy path + 주요 edge case. 각 시나리오는 Done Criteria 중 하나에 매핑.
-- **Out of Scope** — 이번에 하지 않는 것을 명시 (비어 있으면 스코프 팽창 신호).
-- **Assumptions** — 3단계에서 채택한 기본값 전부.
-- **API Contract** (해당 시에만) — 엔드포인트/요청/응답 형태. 이 섹션이 있으면 이후 `/vibe.contract` 가 drift 를 검사한다.
-
-이어서 `.vibe/features/{feature-name}.feature` 를 생성한다: 시나리오 섹션을 gherkin 으로 변환 (Done Criteria ↔ Scenario 매핑 유지). `/vibe.run` 이 이 파일을 구현·검증 단위로 사용한다.
-
-**Large scope** (5+ phases 또는 15+ 신규 파일 또는 4+ 독립 기능): 폴더 분할 — `.vibe/specs/{feature}/_index.md` + `phase-N-{name}.md`, feature 파일도 동일 구조로 매칭. 조용히 분할하고 결과만 보고한다.
-
-**파일 규칙**: `.vibe/` 밖에 파일을 만들지 않는다. SPEC 파일마다 매칭되는 Feature 파일이 있어야 한다.
-
-### 5. Self-review — once
-
-작성 직후, 아래 체크리스트로 자기 SPEC 을 **1회** 점검하고 걸리는 항목을 즉시 고친다. 외부 LLM 리뷰 없음, 수렴 루프 없음 — 한 번 고치면 끝.
-
-- [ ] 모든 Done Criteria 가 명령/관찰로 판정 가능한가 (모델 자기 보고가 아닌)
-- [ ] 모든 시나리오가 Done Criteria 에 매핑되는가 (고아 시나리오 없음)
-- [ ] 수치가 필요한 곳에 수치가 있는가 (제한·타임아웃·크기 — 없으면 기본값 + Assumptions)
-- [ ] Out of Scope 가 비어 있지 않은가
-- [ ] 요구사항에 있던 것 중 SPEC 에서 빠진 것이 없는가
-
-### 6. Approval — the single gate
-
-SPEC 요약(Goal, Done Criteria, 시나리오 수, Out of Scope, 열린 Assumptions)을 제시하고 승인을 받는다:
-
-```
-📋 SPEC 준비 완료: {feature-name}
-   .vibe/specs/{feature-name}.md · .vibe/features/{feature-name}.feature
-
-   Goal: {1줄}
-   Done Criteria: {N}개 (전부 결정론 게이트)
-   Scenarios: {M}개 · Out of Scope: {K}항목
-   Assumptions: {요약 또는 "없음"}
-
-승인하면 이 SPEC 이 루프의 Done 정의가 됩니다.
-[1] 승인 → 구현 진행   [2] 수정 요청   [3] 중단
-```
-
-- 수정 요청 → 반영 후 재제시 (사용자 주도 반복 — 자동 루프 아님).
-- `automationLevel: autonomous` → 승인 생략, 요약만 출력하고 진행.
-- 승인 후 SPEC 변경은 코드 변경과 같은 커밋으로 (SPEC-First — `vibe.run` 참조).
-
-## Output
-
-| 파일 | 경로 |
-|---|---|
-| SPEC | `.vibe/specs/{feature-name}.md` (또는 분할 폴더) |
-| Feature (BDD) | `.vibe/features/{feature-name}.feature` (또는 분할 폴더) |
-| Pointer | `.vibe/.last-feature` |
-
-승인된 SPEC 은 루프의 ANCHOR 로 쓰인다: `/vibe.run` 이 시나리오 단위로 구현·검증하고, `/vibe.verify` 가 Done Criteria 를 판정해 `.vibe/metrics/run-ledger.json` 의 `verifyPassed` 를 기록한다. 게이트 통과 여부는 항상 run-ledger·테스트 exit code 가 판정한다.
-
-## Next Step
-
-```
-/vibe.run "{feature-name}"
-```
-
----
-
-ARGUMENTS: $ARGUMENTS

package/skills/test/SKILL.md

@@ -1,140 +0,0 @@
----
-name: test
-description: vibe 자가검진 본체 — 대상 harness(~/.claude/~/.codex)의 모든 entry skill/skill/hook/agent 프로빙 → pass/fail 리포트 → ~/.vibe/test-reports/.
-when_to_use: vibe.test 진입점에서 체인 호출. 직접 호출 금지.
-user-invocable: false
-tier: core
----
-
-# test — Self-Test
-
-Probe every shipped vibe surface in one install dir and emit a pass/fail report.
-
-## Why this exists
-
-When vibe ships new entry skills, skills, hooks, or agents, one side (CC or Codex) can end up out of sync with the other, frontmatter can drift, and hook tests can silently break. `vibe.test` is the single mechanical check: does every surface in the target install actually load and pass its own tests?
-
-## Target harness
-
-The argument selects which install dir to probe:
-
-| Arg | Probed dir |
-|---|---|
-| (empty) | current harness — CC: `~/.claude/`, Codex: `~/.codex/` |
-| `cc` | `~/.claude/` |
-| `codex` | `~/.codex/` |
-
-If the target dir does not exist, print a clear message and exit with guidance (not an error). Example:
-
-```
-~/.codex/ not found — Codex isn't installed on this machine.
-  To install: npm i -g @openai/codex
-```
-
-## Probes
-
-All probes are **structural or test-based** — no interactive command is ever actually invoked, and no LLM is called.
-
-| Category | Source | Check |
-|---|---|---|
-| entry skills | `<install>/skills/vibe*/SKILL.md` | file readable · frontmatter parses · `name`, `description`, `user-invocable: true` present |
-| skills | `<install>/skills/*/SKILL.md` | frontmatter parses · required fields (`name`, `description`) · body non-empty |
-| hooks | repo `hooks/scripts/*.js` | for each script with a matching `__tests__/<name>.test.js`, run `npx vitest run <test> --reporter=json` and parse pass/fail counts |
-| agents | `<install>/agents/*.md` | file readable · frontmatter parses · required fields (`name`, `description`) |
-
-A probe's failure is captured in its `error` field; the overall run never halts because of one failure.
-
-## Report template
-
-Written to `~/.vibe/test-reports/<YYYYMMDD-HHmm>-<harness>.{json,md}`. Exact schema:
-
-### JSON
-
-```json
-{
-  "harness": "cc",
-  "timestamp": "2026-04-16T18:30:00+09:00",
-  "vibe_version": "2.9.24",
-  "install_dir": "/Users/grove/.claude",
-  "summary": {
-    "total": 42,
-    "passed": 40,
-    "failed": 2
-  },
-  "probes": {
-    "entrySkills": [
-      { "name": "vibe.spec", "status": "pass" },
-      { "name": "vibe.test", "status": "pass" }
-    ],
-    "skills": [
-      { "name": "test", "status": "pass" },
-      { "name": "spec", "status": "fail", "error": "invocation includes `auto` but triggers array is empty" }
-    ],
-    "hooks": [
-      { "name": "pre-tool-guard", "status": "pass", "tests": "38/38" },
-      { "name": "scope-guard", "status": "pass", "tests": "12/12" }
-    ],
-    "agents": [
-      { "name": "implementer", "status": "pass" }
-    ]
-  },
-  "failed": [
-    {
-      "category": "skills",
-      "name": "spec",
-      "error": "frontmatter: triggers array is empty"
-    }
-  ]
-}
-```
-
-- `status`: `"pass"` | `"fail"`
-- `error`: required when `status === "fail"`, omitted otherwise
-- `tests` (hooks only): short `passed/total` string from the vitest JSON reporter
-- `failed[]`: flat list of every failure for quick scanning — mirrors entries found across `probes.*`
-
-### Markdown
-
-```markdown
-# vibe self-test · cc · 2026-04-16 18:30
-
-**Version**: 2.9.24   **Install**: /Users/grove/.claude
-
-| Category | Pass | Fail |
-|---|---:|---:|
-| entry skills | 15 | 0 |
-| skills   | 17 | 1 |
-| hooks    |  6 | 0 |
-| agents   |  3 | 1 |
-| **total**| **41** | **2** |
-
-## Failures
-
-- **skills / spec** — invocation includes `auto` but triggers array is empty
-- **agents / implementer** — agent file not found
-```
-
-If `failed` is empty, replace the Failures section with `_All probes passed._`.
-
-## Steps
-
-1. **Resolve target**: argument (`cc` / `codex` / empty). Empty → detect current harness (`$CLAUDE_PROJECT_DIR` set → `cc`; else fall back to `cc`).
-2. **Resolve install dir**: `cc` → `~/.claude`, `codex` → `~/.codex`. If missing → print guidance + exit.
-3. **Read `vibe_version`** from `package.json` in the current repo.
-4. **Walk each category**, run its check, append `{ name, status, error? }` to `probes.<category>`.
-5. **Compute** `summary` counts and the flat `failed[]` list.
-6. **Ensure** `~/.vibe/test-reports/` exists (`mkdir -p`, dir mode `0o700` — consistent with `~/.vibe/config.json`).
-7. **Write** `<ts>-<harness>.json` and `<ts>-<harness>.md`.
-8. **Print** the Markdown summary to the console.
-9. **If `summary.failed > 0`**, load skill `regress` with `subcommand: register --from-test` and pass the failed entries. P1 = any probe with `status: fail`.
-
-## Done Criteria
-
-- [ ] No external LLM call — file reads + vitest runs only
-- [ ] One probe failing never halts the overall run
-- [ ] Target install dir missing → clean exit with guidance (not an error)
-- [ ] JSON report matches the template above exactly (fields, types, naming)
-- [ ] Markdown summary printed to console after the run
-- [ ] Reports land in `~/.vibe/test-reports/`, never in project-local `.vibe/`
-- [ ] `failed.length > 0` → auto-invokes `vibe.regress register --from-test`
-- [ ] Entry skills are verified as user-invocable skill surfaces, not deprecated command files