@su-record/vibe 3.2.64 → 4.0.1

package/skills/vibe.reason/references/output-format-template.md

@@ -1,57 +0,0 @@
-# vibe.reason — Output Format Template
-
-> Loaded by vibe.reason SKILL.md Output Format — full markdown report template for the 9-step reasoning framework analysis.
-
-## Output Format
-
-```markdown
-# Reasoning Framework Analysis
-
-**Problem**: [problem description]
-**Context**: [relevant information]
-**Steps Applied**: 9/9
-**⏱️ Started**: {start_time}
-**⏱️ Completed**: {getCurrentTime 결과}
-
----
-
-## 1. Logical Dependencies and Constraints
-
-**Constraint Analysis**:
-[analysis content]
-
----
-
-## 2. Risk Assessment
-
-**Risk Assessment**:
-- Task type: [risk level]
-- Rollback possibility: [assessment]
-- Compatibility/Security/Performance risks
-
----
-
-## 3. Inductive Reasoning and Hypothesis Exploration
-
-**Hypothesis Generation**:
-1. **Hypothesis 1**: [description] (Likelihood: High/Medium/Low)
-   - Evidence: [supporting evidence]
-   - Verification: [how to verify]
-
-2. **Hypothesis 2**: ...
-
----
-
-[Steps 4-9...]
-
----
-
-## Summary
-
-[Overall reasoning results summary and recommendations]
-
-**Recommended Actions**:
-1. Immediate: [low risk action]
-2. Short-term: [medium priority]
-3. Medium-term: [long-term fix]
-```

package/skills/vibe.reason/references/quality-rubrics.md

@@ -1,94 +0,0 @@
-# vibe.reason — Quality Rubrics
-
-> Loaded by vibe.reason SKILL.md Quality Gate (Mandatory) — full reasoning quality checklist, hypothesis quality standards, minimum hypothesis count, evidence standards, risk assessment matrix, forbidden reasoning patterns, and reasoning output requirements. Reasoning Score Calculation (the deterministic gate threshold) stays in SKILL.md.
-
-### Reasoning Quality Checklist
-
-Before completing reasoning analysis, ALL steps must be verified:
-
-| Step | Check Item | Weight |
-|------|------------|--------|
-| **Step 1** | Logical dependencies and constraints identified | 10% |
-| **Step 2** | Risk assessment completed with rollback plan | 10% |
-| **Step 3** | At least 3 hypotheses generated with likelihood | 15% |
-| **Step 4** | Verification method defined for each hypothesis | 10% |
-| **Step 5** | All available tools and resources listed | 10% |
-| **Step 6** | Evidence cited with exact sources | 15% |
-| **Step 7** | All alternatives explored | 10% |
-| **Step 8** | Error handling strategy defined | 10% |
-| **Step 9** | Action plan documented before execution | 10% |
-
-
-### Hypothesis Quality Standards
-
-Each hypothesis MUST include:
-
-| Component | Requirement | Example |
-|-----------|-------------|---------|
-| **Description** | Clear, testable statement | "Session data is incomplete due to race condition" |
-| **Likelihood** | High/Medium/Low with justification | "High - intermittent = timing issue" |
-| **Evidence** | Supporting observations | "Error only on concurrent logins" |
-| **Verification** | Specific test method | "Add logging to session.save()" |
-| **Disproof criteria** | What would rule it out | "Logs show complete data every time" |
-
-### Minimum Hypothesis Count
-
-| Problem Complexity | Minimum Hypotheses |
-|--------------------|-------------------|
-| Simple (single component) | 2 |
-| Medium (cross-component) | 3 |
-| Complex (system-wide) | 5 |
-
-### Evidence Standards
-
-All claims MUST include:
-
-| Evidence Type | Required Format |
-|---------------|-----------------|
-| Code reference | `filename.ts:L42` |
-| Log/metric | Exact value with timestamp |
-| Documentation | Document name + section |
-| Prior knowledge | Memory key or conversation reference |
-
-### Risk Assessment Matrix
-
-| Risk Level | Rollback Required | Approval Required |
-|------------|-------------------|-------------------|
-| **Low** | Optional | No |
-| **Medium** | Yes, automated | No |
-| **High** | Yes, tested | User confirmation |
-| **Critical** | Yes, verified | User + backup plan |
-
-### Forbidden Reasoning Patterns
-
-| Pattern | Issue | Required Fix |
-|---------|-------|--------------|
-| "Probably X" without evidence | Unsubstantiated claim | Add supporting evidence |
-| Single hypothesis | Tunnel vision | Generate alternatives |
-| Skipping risk assessment | Dangerous changes | Always assess risk |
-| "I think" without verification | Assumption | Verify before claiming |
-| Acting before reasoning complete | Premature action | Complete all 9 steps |
-
-### Reasoning Output Requirements
-
-Every reasoning analysis MUST include:
-
-1. **Problem Statement**
-   - Clear description
-   - Context and constraints
-   - Steps applied count (X/9)
-
-2. **Hypothesis Table**
-   - Ranked by likelihood
-   - All 5 components per hypothesis
-   - Verification status
-
-3. **Risk Assessment**
-   - Risk level classification
-   - Rollback possibility
-   - Approval requirements
-
-4. **Recommended Actions**
-   - Immediate (low risk, high confidence)
-   - Short-term (medium priority)
-   - Long-term (systemic fix)

package/skills/vibe.reason/references/worked-example.md

@@ -1,45 +0,0 @@
-# vibe.reason — Worked Example
-
-> Loaded by vibe.reason SKILL.md Example — full worked example applying the 9-step reasoning framework to a debugging scenario.
-
-## Example
-
-```
-User: /vibe.reason "After user login, profile page intermittently returns 500 error"
-
-AI: Analyzing with 9-step reasoning framework...
-
-# Reasoning Framework Analysis
-
-**Problem**: Intermittent 500 error on profile page after login
-**Context**: Intermittent occurrence, happens after successful login
-
-## 1. Logical Dependencies and Constraints
-
-**Constraint Analysis**:
-- Policy/Rules: Need to check auth/authz system policies
-- Task Order: Verify login -> session creation -> profile fetch order
-- Prerequisites: Need to identify error reproduction conditions
-
-## 3. Inductive Reasoning and Hypothesis Exploration
-
-**Hypothesis Generation**:
-1. **Hypothesis 1: Incomplete session data** (Likelihood: High)
-   - Evidence: Intermittent = timing issue or data consistency problem
-   - Verification: Add logging to session save logic
-
-2. **Hypothesis 2: Async processing order issue** (Likelihood: Medium)
-   - Evidence: undefined = accessing data before load
-   - Verification: Check Promise chain, missing await
-
-## Summary
-
-**Key Findings**:
-- Most likely cause: Incomplete session data
-- Verification priority: 1) Session logging -> 2) Async review -> 3) DB check
-
-**Recommended Actions**:
-1. Immediate: Add detailed logging to session save/fetch
-2. Short-term: Code review async processing
-3. Medium-term: Strengthen session store monitoring
-```

package/skills/vibe.regress/SKILL.md

@@ -1,233 +0,0 @@
----
-name: vibe.regress
-description: Use when a reproduced bug must be registered, turned into a preventive test, or clustered into a recurring root-cause pattern.
-argument-hint: "register | generate | list | import | cluster [args]"
-user-invocable: true
----
-
-# /vibe.regress
-
-**Regression Auto-Evolution** — never fix the same bug twice.
-
-> Bugs are recorded, preventive tests are generated automatically, and recurring patterns get promoted into shared tests.
-
-## Usage
-
-```
-/vibe.regress register "<symptom>"           # Manual register (rare — most calls are automatic)
-/vibe.regress generate <slug>                # bug record → vitest file
-/vibe.regress list                           # Open items
-/vibe.regress import                         # Backfill from git log `fix:` commits
-/vibe.regress cluster                        # 3+ similar bugs → propose shared test
-```
-
-## Auto-integration
-
-- `/vibe.verify` failure → auto-invokes `register` (no manual step)
-- `/vibe.run "<feature>"` start → warns about open regressions for that feature
-
-## Process
-
-Execute the bundled implementation below with subcommand: `$ARGUMENTS`
-
-The `regress` skill performs registration, generation, and clustering.
-
-**Core steps** (see `skills/vibe.regress/SKILL.md` for details):
-
-1. Parse subcommand
-2. Read/write `.vibe/regressions/<slug>.md` (frontmatter schema enforced)
-3. On `generate`, detect the project's test stack → choose template (vitest / jest)
-4. On `cluster`, group by `root-cause-tag`; ≥3 entries → propose a shared test
-5. On `import`, parse `git log --grep='^fix:'`; skip duplicates by commit hash
-
-## Output
-
-- `.vibe/regressions/<slug>.md` — bug record (frontmatter + reproduction / root cause)
-- Project test dir — generated vitest file (`*.regression.test.ts`)
-- `list` prints a terminal table
-
-## Storage Format
-
-회귀 항목의 저장 위치와 frontmatter 스키마는 아래 **Storage Contract** 절이 SSOT다.
-`root-cause-tag` 허용값 목록도 그쪽에만 둔다 — 두 곳에 두면 한쪽이 조용히 낡는다.
-
-## Bundled implementation
-
-
-# vibe.regress — Regression Auto-Evolution
-
-**Purpose**: never fix the same bug twice. Each fix grows a preventive test.
-
-## Why this exists
-
-A classic vibe-coding weakness: LLMs reintroduce bugs of the same class. Regression tests are the only mechanical defense. But if the human has to write the test every time, it gets skipped — so automate.
-
-## Characterization — lock behavior first
-
-Before modifying legacy or untested code whose behavior is uncertain (large files without tests, complex branching, API contracts), **lock current behavior first, then change**:
-
-1. Generate characterization tests over the public surface — snapshot the **actual** output (`toMatchSnapshot()`), not what you think it should be. Do NOT fix bugs while locking: a wrong value gets locked as-is; the goal is regression detection, not correctness.
-2. Run them — all must pass against the unmodified code. A failure means the characterization is wrong: fix the test, never the code.
-3. Make the change incrementally, re-running after each step. Unexpected failure = regression, stop and investigate.
-4. Reconcile: update snapshots only for **intentionally** changed behavior, and add new tests for the new behavior.
-
-Skip this for code you just wrote, already-well-tested code, or trivial changes — write regular unit tests instead. Test file naming/stack detection follows `generate` (below).
-
-## Storage Contract
-
-```
-.vibe/regressions/
-  <bug-slug>.md       # one file per bug
-  _cluster-<tag>.md   # shared-test design produced by `cluster`
-```
-
-### Frontmatter schema (strict)
-
-```yaml
-slug: string            # kebab-case, globally unique
-symptom: string         # one line, user-facing
-root-cause-tag: enum    # only the allowed tags below
-fix-commit: string      # git hash (or "pending")
-test-path: string       # generated test file path (or "pending")
-status: open | test-generated | resolved
-registered: YYYY-MM-DD
-feature: string         # related feature name (matches SPEC)
-```
-
-### Allowed `root-cause-tag` values
-
-Clustering depends on this, so use **only the predefined set**:
-
-- `timezone` — timezone / DST / off-by-one in time
-- `nullability` — null / undefined / empty handling
-- `concurrency` — race conditions
-- `boundary` — off-by-one, edge values
-- `encoding` — charset, URL encoding, escaping
-- `validation` — missing input validation
-- `auth` — authn/authz logic
-- `state-sync` — client/server state mismatch
-- `integration` — external API call failure
-- `type-narrow` — TypeScript type narrowing mistake
-- `other` — when nothing fits (add new tags later)
-
-**Rule**: if a new tag is needed, do not force-fit into an existing one — register as `other`. Once `other` reaches 3 entries, propose adding a new tag.
-
-## Subcommands
-
-### 1. `register "<symptom>"` — manual registration
-
-Most calls are automatic; manual use is rare (bugs found outside `/vibe.verify`, or production incidents).
-
-**Steps**:
-1. Query the system clock for today's date
-2. `git log -1 --format=%H` for current commit hash (fix-commit candidate)
-3. Conversation extracts:
-   - Reproduction steps (Given/When/Then)
-   - Root-cause paragraph
-   - Fix description
-4. `root-cause-tag` is **inferred from the allowed set, then confirmed with the user**. If unclear → `other`.
-5. Generate slug: kebab-case keywords from the symptom; on collision append `-2`
-6. Write `.vibe/regressions/<slug>.md` (status: `open`)
-
-### 2. `generate <slug>` — generate preventive test
-
-**Steps**:
-1. Read bug file
-2. Detect test stack:
-   - From `package.json` `devDependencies`: prefer `vitest` over `jest`
-   - If neither → **ask user, then stop**
-3. Decide test location:
-   - Sibling `__tests__/` next to the implementation file, OR
-   - The project's existing test dir (vitest config `test.include`)
-4. File name: `<original-file>.regression.test.ts`
-5. Body: render `templates/test-template.md`; set `{{TEST_RUNNER_IMPORT}}` to the Vitest import below or an empty string for Jest globals:
-   - Vitest: `import { describe, it, expect{{EXTRA_IMPORTS}} } from 'vitest';`
-6. Update bug frontmatter: `test-path`, `status: test-generated`
-7. **Run the test immediately** — should fail (if not yet fixed) or pass (if fixed). Record outcome in frontmatter.
-
-### 3. `list` — open items
-
-```
-/vibe.regress list                 # status != resolved
-/vibe.regress list --feature login # filter by feature
-/vibe.regress list --tag timezone  # filter by tag
-```
-
-Terminal table:
-
-```
-SLUG                              FEATURE   TAG         STATUS           AGE
-login-jwt-expiry-off-by-one       login     timezone    test-generated   3d
-cart-stock-race-double-deduct     cart      concurrency open             1d
-```
-
-### 4. `import` — backfill from git log
-
-**Steps**:
-1. `git log --grep='^fix:' --format='%H|%s|%ci' --since=<last-import-date>`
-   - `last-import-date` lives in `.vibe/regressions/.import-cursor` (defaults to 90 days ago)
-2. For each commit:
-   - If a bug file with the same `fix-commit` already exists → **skip**
-   - Otherwise infer symptom + root-cause-tag from message/diff (LLM call)
-   - Write a new bug file (status: `resolved` — already fixed)
-3. Update `.import-cursor`
-4. Suggest `generate` for newly imported entries
-
-**Note**: only `fix:` commits are considered. Projects not using Conventional Commits can override with `--grep-pattern`.
-
-### 5. `cluster` — promote recurring patterns
-
-**Steps**:
-1. Aggregate `root-cause-tag` across all bug files
-2. **A tag with ≥3 entries** becomes a cluster candidate
-3. For each candidate:
-   - Feed the 3 reproductions to an LLM to extract the common cause and shared test cases
-   - Write `_cluster-<tag>.md` (links to the original bug slugs)
-   - Propose a shared test skeleton at `<project-test-dir>/_cluster-<tag>.regression.test.ts` (create only with user approval)
-4. Original bug files are **not deleted** — history preserved
-
-**Important**: `cluster` is never automatic. Users invoke it explicitly to avoid premature abstraction.
-
-## Integration with /vibe.verify
-
-When `/vibe.verify` fails it calls:
-
-```
-Load skill `vibe.regress` with: register --from-verify
-  <feature>: {feature-name}
-  <scenario>: {failed-scenario}
-  <error>: {error-message}
-  <location>: {file:line}
-```
-
-`--from-verify` behavior:
-- symptom = scenario name + error summary
-- feature = forwarded feature name
-- root-cause-tag = inferred from error pattern (default `other` if unclear)
-- status = `open`
-- **Skip user confirmation** — the user is already attentive in a verify-failure context, and friction must be minimized
-
-## Integration with /vibe.run
-
-At the start of `/vibe.run "<feature>"`:
-
-1. Filter `.vibe/regressions/*.md` for `feature: <feature-name>` + `status != resolved`
-2. If any open items:
-   ```
-   ⚠️  Open regressions for this feature:
-     - login-jwt-expiry-off-by-one (timezone, 3d old)
-     - login-session-leak (auth, 1w old)
-
-   Fix these before adding new behavior? [y/N]
-   ```
-3. `y` → chain to `/vibe.regress generate` for items not yet test-generated
-4. `N` → continue (ultrawork mode auto-`N`, records TODO)
-
-## Done Criteria
-
-- [ ] Subcommand-less invocation prints usage
-- [ ] Frontmatter schema strictly enforced (missing fields rejected)
-- [ ] `root-cause-tag` outside the allowed set → warn + force `other`
-- [ ] After `generate`, the test is **actually run** to verify
-- [ ] `import` deduplicates by `fix-commit` hash
-- [ ] `cluster` does nothing under 3 entries (false-positive guard)

package/skills/vibe.regress/templates/bug.md

@@ -1,44 +0,0 @@
----
-slug: {{SLUG}}
-symptom: "{{SYMPTOM}}"
-root-cause-tag: {{ROOT_CAUSE_TAG}}
-fix-commit: {{FIX_COMMIT}}
-test-path: {{TEST_PATH}}
-status: {{STATUS}}
-registered: {{DATE}}
-feature: {{FEATURE}}
----
-
-# {{SLUG}}
-
-## Symptom
-
-{{SYMPTOM_DETAIL}}
-
-## Reproduction
-
-**Given**: {{GIVEN}}
-
-**When**: {{WHEN}}
-
-**Then** (broken behavior): {{THEN_BROKEN}}
-
-**Expected**: {{THEN_EXPECTED}}
-
-## Root cause
-
-{{ROOT_CAUSE_EXPLANATION}}
-
-## Fix
-
-{{FIX_EXPLANATION}}
-
-## Related
-
-- Feature: [.vibe/features/{{FEATURE}}.feature](../../features/{{FEATURE}}.feature)
-- Fix commit: `{{FIX_COMMIT}}`
-- Regression test: `{{TEST_PATH}}`
-
-## Notes
-
-{{NOTES}}

package/skills/vibe.regress/templates/test-template.md

@@ -1,30 +0,0 @@
-/**
- * Regression test — {{SLUG}}
- *
- * Symptom: {{SYMPTOM}}
- * Root cause tag: {{ROOT_CAUSE_TAG}}
- * Fix commit: {{FIX_COMMIT}}
- * Source record: .vibe/regressions/{{SLUG}}.md
- *
- * DO NOT delete this test when the bug is fixed — it exists to prevent the
- * same bug from being reintroduced. Update only if the reproduction steps
- * in the source record change.
- */
-
-{{TEST_RUNNER_IMPORT}}
-{{IMPORTS_FROM_SUT}}
-
-describe('regression: {{SYMPTOM_SHORT}}', () => {
-  it('{{TEST_NAME}}', {{ASYNC}}() => {
-    // Given: {{GIVEN}}
-    {{GIVEN_CODE}}
-
-    // When: {{WHEN}}
-    {{WHEN_CODE}}
-
-    // Then: {{THEN}}
-    {{THEN_ASSERTIONS}}
-  });
-
-  {{EXTRA_IT_BLOCKS}}
-});