gsd-trae 1.0.1 → 1.0.2

package/refs/vbenchmark/.claude/commands/agentic-dev/done.md

@@ -1,166 +0,0 @@
-# Done Phase
-
-Archive completed change and update specs.
-
-**Arguments:** `$ARGUMENTS` (change-id)
-
-## Process
-
-```dot
-digraph archive_flow {
-    rankdir=TB;
-
-    "1. Get change-id" [shape=box];
-    "2. Verify all tasks completed" [shape=box];
-    "All tasks done?" [shape=diamond];
-    "Report incomplete tasks" [shape=box];
-    "3. Run openspec archive" [shape=box];
-    "4. Validate specs updated" [shape=box];
-    "Validation passes?" [shape=diamond];
-    "Investigate and fix" [shape=box];
-    "5. Output ARCHIVE COMPLETE" [shape=box];
-
-    "1. Get change-id" -> "2. Verify all tasks completed";
-    "2. Verify all tasks completed" -> "All tasks done?";
-    "All tasks done?" -> "Report incomplete tasks" [label="no"];
-    "All tasks done?" -> "3. Run openspec archive" [label="yes"];
-    "3. Run openspec archive" -> "4. Validate specs updated";
-    "4. Validate specs updated" -> "Validation passes?";
-    "Validation passes?" -> "Investigate and fix" [label="no"];
-    "Investigate and fix" -> "4. Validate specs updated";
-    "Validation passes?" -> "5. Output ARCHIVE COMPLETE" [label="yes"];
-}
-```
-
-## Step 1: Get Change ID
-
-The change-id should be provided as argument:
-```
-/agentic-dev:done add-shortcuts
-```
-
-If not provided, check active changes:
-```bash
-openspec list
-```
-
-## Step 2: Verify All Tasks Completed
-
-Read `openspec/changes/<change-id>/tasks.md` and check:
-
-```bash
-# Count uncompleted tasks
-grep -c '\- \[ \]' openspec/changes/<change-id>/tasks.md
-```
-
-If ANY `- [ ]` items remain:
-- List the uncompleted tasks
-- Ask user to complete them first OR
-- In Ralph Loop mode, output error and stop
-
-**Do NOT archive with incomplete tasks.**
-
-## Step 3: Run Archive Command
-
-```bash
-openspec archive <change-id> --yes
-```
-
-Flags:
-- `--yes`: Skip confirmation prompts (for automation)
-- `--skip-specs`: Only for tooling-only changes (no spec updates needed)
-
-Expected output:
-- Change moved to `openspec/changes/archive/YYYY-MM-DD-<change-id>/`
-- Specs updated in `openspec/specs/`
-
-## Step 4: Validate
-
-```bash
-openspec validate --strict
-```
-
-Check that:
-1. Archive directory exists with correct date prefix
-2. Specs were updated (check `openspec/specs/<capability>/spec.md`)
-3. No validation errors
-
-If validation fails:
-```bash
-openspec show <change-id> --json
-openspec list --specs
-```
-
-## Step 5: Update Documentation
-
-Update project documentation to reflect completed change:
-
-### README.md
-- Remove entry from "Active Changes" table (now archived)
-- Add new features/tools to main documentation sections
-- Update Quick Start if new commands available
-- Update Architecture diagram if structure changed
-
-### CLAUDE.md
-- Finalize any command documentation
-- Update workflow instructions if affected
-- Ensure all new capabilities are documented
-
-## Step 6: Complete
-
-When archive, validation, and docs are updated:
-
-```
-<promise>ARCHIVE COMPLETE</promise>
-```
-
-## Post-Archive Summary
-
-Output a summary:
-
-```markdown
-## Archive Complete
-
-**Change:** add-shortcuts
-**Archived to:** openspec/changes/archive/2024-01-16-add-shortcuts/
-**Specs updated:**
-- openspec/specs/shortcuts/spec.md (new)
-- openspec/specs/settings/spec.md (modified)
-
-All validation checks passed.
-```
-
-## Red Flags
-
-- Archiving with incomplete tasks
-- Skipping validation
-- Not checking specs were actually updated
-- Archiving wrong change-id
-
-## Troubleshooting
-
-### Archive command fails
-```bash
-# Check change exists and is not already archived
-openspec list
-openspec show <change-id>
-```
-
-### Specs not updated
-```bash
-# Check deltas were correct
-openspec show <change-id> --json --deltas-only
-
-# Manually inspect specs
-ls openspec/specs/
-cat openspec/specs/<capability>/spec.md
-```
-
-### Validation errors after archive
-```bash
-# Full validation output
-openspec validate --strict
-
-# Check specific spec
-openspec show <spec-id> --type spec --json
-```

package/refs/vbenchmark/.claude/commands/agentic-dev/proposal.md

@@ -1,220 +0,0 @@
-# Proposal Phase
-
-Create OpenSpec change proposal through collaborative exploration.
-
-## Process
-
-```dot
-digraph proposal_flow {
-    rankdir=TB;
-
-    "1. Check current state" [shape=box];
-    "2. Explore requirements (one Q at a time)" [shape=box];
-    "3. Present 2-3 approaches" [shape=box];
-    "User chooses approach" [shape=diamond];
-    "4. Generate OpenSpec files" [shape=box];
-    "5. Validate with openspec" [shape=box];
-    "Validation passes?" [shape=diamond];
-    "Fix issues" [shape=box];
-    "6. Output PROPOSAL COMPLETE promise" [shape=box];
-
-    "1. Check current state" -> "2. Explore requirements (one Q at a time)";
-    "2. Explore requirements (one Q at a time)" -> "3. Present 2-3 approaches";
-    "3. Present 2-3 approaches" -> "User chooses approach";
-    "User chooses approach" -> "4. Generate OpenSpec files";
-    "4. Generate OpenSpec files" -> "5. Validate with openspec";
-    "5. Validate with openspec" -> "Validation passes?";
-    "Validation passes?" -> "Fix issues" [label="no"];
-    "Fix issues" -> "5. Validate with openspec";
-    "Validation passes?" -> "6. Output PROPOSAL COMPLETE promise" [label="yes"];
-}
-```
-
-## Step 1: Check Current State
-
-Before exploring, understand the codebase:
-
-```bash
-openspec list              # Active changes
-openspec list --specs      # Existing capabilities
-```
-
-Check for conflicts or related work.
-
-## Step 2: Explore Requirements
-
-**One question at a time.** Prefer multiple choice when possible.
-
-Example questions:
-- "What's the primary use case for this feature?"
-- "Should this be user-configurable?"
-- "Which existing components does this interact with?"
-- "What's the expected error behavior?"
-
-**Stop exploring when you have enough to propose approaches.**
-
-## Step 3: Present Approaches
-
-Present 2-3 approaches with trade-offs:
-
-```markdown
-I've identified 3 possible approaches:
-
-**A) [Name] (Recommended)**
-- Pros: ...
-- Cons: ...
-- Effort: Low/Medium/High
-
-**B) [Name]**
-- Pros: ...
-- Cons: ...
-- Effort: ...
-
-**C) [Name]**
-- Pros: ...
-- Cons: ...
-- Effort: ...
-
-I recommend A because [reason]. Which approach would you prefer?
-```
-
-## Step 4: Generate OpenSpec Files
-
-Create files under `openspec/changes/<change-id>/`:
-
-### 4.1 Choose change-id
-- Kebab-case, verb-led: `add-shortcuts`, `update-auth-flow`, `remove-legacy-api`
-- Must be unique (check with `openspec list`)
-
-### 4.2 Create proposal.md
-
-```markdown
-# Change: [Brief description]
-
-## Why
-[1-2 sentences on problem/opportunity]
-
-## What Changes
-- [Bullet list of changes]
-- [Mark breaking changes with **BREAKING**]
-
-## Impact
-- Affected specs: [list capabilities]
-- Affected code: [key files/systems]
-```
-
-### 4.3 Create design.md (if needed)
-
-Create only if:
-- Cross-cutting change (multiple services/modules)
-- New external dependency
-- Security/performance implications
-- Architectural decisions needed
-
-```markdown
-## Context
-[Background, constraints]
-
-## Goals / Non-Goals
-- Goals: [...]
-- Non-Goals: [...]
-
-## Decisions
-- Decision: [What and why]
-- Alternatives: [Options considered]
-
-## Risks / Trade-offs
-- [Risk] -> Mitigation
-```
-
-### 4.4 Create tasks.md
-
-Use TDD-style format for Ralph Loop compatibility:
-
-```markdown
-## 1. Implementation
-
-### Task 1.1: [Component Name]
-
-**Files:**
-- Create: `exact/path/to/file.ts`
-- Modify: `exact/path/to/existing.ts:123-145`
-- Test: `tests/path/to/test.ts`
-
-**Steps:**
-- [ ] 1.1.1 Write failing test
-- [ ] 1.1.2 Run test, verify failure
-- [ ] 1.1.3 Implement minimal code
-- [ ] 1.1.4 Run test, verify pass
-- [ ] 1.1.5 Commit
-
-### Task 1.2: [Next Component]
-...
-```
-
-### 4.5 Create spec deltas
-
-Under `openspec/changes/<id>/specs/<capability>/spec.md`:
-
-```markdown
-## ADDED Requirements
-
-### Requirement: [Name]
-The system SHALL [behavior].
-
-#### Scenario: [Success case]
-- **WHEN** [condition]
-- **THEN** [expected result]
-
-## MODIFIED Requirements
-[Full updated requirement text - not partial]
-
-## REMOVED Requirements
-### Requirement: [Name]
-**Reason**: [Why removing]
-**Migration**: [How to handle]
-```
-
-## Step 5: Validate
-
-```bash
-openspec validate <change-id> --strict
-```
-
-If validation fails:
-- Check scenario format: must be `#### Scenario:` (4 hashtags)
-- Check requirement has at least one scenario
-- Check delta operations: `## ADDED|MODIFIED|REMOVED Requirements`
-
-Debug with:
-```bash
-openspec show <change-id> --json --deltas-only
-```
-
-## Step 6: Update Documentation
-
-Update project documentation to reflect the new proposal:
-
-### README.md
-- Add entry to "Active Changes" table with change-id, description, status "Proposed"
-- Update any affected architecture/feature sections if relevant
-
-### CLAUDE.md
-- No changes typically needed for proposal phase
-- Only update if the change affects development workflow
-
-## Step 7: Complete
-
-When validation passes and docs are updated:
-
-```
-<promise>PROPOSAL COMPLETE</promise>
-```
-
-## Red Flags
-
-- Writing code during proposal phase (don't!)
-- Skipping validation
-- Creating spec deltas without scenarios
-- Using MODIFIED without full requirement text
-- Proposing without exploring requirements first

package/refs/vbenchmark/.claude/commands/openspec/apply.md

@@ -1,23 +0,0 @@
----
-name: OpenSpec: Apply
-description: Implement an approved OpenSpec change and keep tasks in sync.
-category: OpenSpec
-tags: [openspec, apply]
----
-<!-- OPENSPEC:START -->
-**Guardrails**
-- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
-- Keep changes tightly scoped to the requested outcome.
-- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
-
-**Steps**
-Track these steps as TODOs and complete them one by one.
-1. Read `changes/<id>/proposal.md`, `design.md` (if present), and `tasks.md` to confirm scope and acceptance criteria.
-2. Work through tasks sequentially, keeping edits minimal and focused on the requested change.
-3. Confirm completion before updating statuses—make sure every item in `tasks.md` is finished.
-4. Update the checklist after all work is done so each task is marked `- [x]` and reflects reality.
-5. Reference `openspec list` or `openspec show <item>` when additional context is required.
-
-**Reference**
-- Use `openspec show <id> --json --deltas-only` if you need additional context from the proposal while implementing.
-<!-- OPENSPEC:END -->

package/refs/vbenchmark/.claude/commands/openspec/archive.md

@@ -1,27 +0,0 @@
----
-name: OpenSpec: Archive
-description: Archive a deployed OpenSpec change and update specs.
-category: OpenSpec
-tags: [openspec, archive]
----
-<!-- OPENSPEC:START -->
-**Guardrails**
-- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
-- Keep changes tightly scoped to the requested outcome.
-- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
-
-**Steps**
-1. Determine the change ID to archive:
-   - If this prompt already includes a specific change ID (for example inside a `<ChangeId>` block populated by slash-command arguments), use that value after trimming whitespace.
-   - If the conversation references a change loosely (for example by title or summary), run `openspec list` to surface likely IDs, share the relevant candidates, and confirm which one the user intends.
-   - Otherwise, review the conversation, run `openspec list`, and ask the user which change to archive; wait for a confirmed change ID before proceeding.
-   - If you still cannot identify a single change ID, stop and tell the user you cannot archive anything yet.
-2. Validate the change ID by running `openspec list` (or `openspec show <id>`) and stop if the change is missing, already archived, or otherwise not ready to archive.
-3. Run `openspec archive <id> --yes` so the CLI moves the change and applies spec updates without prompts (use `--skip-specs` only for tooling-only work).
-4. Review the command output to confirm the target specs were updated and the change landed in `changes/archive/`.
-5. Validate with `openspec validate --strict` and inspect with `openspec show <id>` if anything looks off.
-
-**Reference**
-- Use `openspec list` to confirm change IDs before archiving.
-- Inspect refreshed specs with `openspec list --specs` and address any validation issues before handing off.
-<!-- OPENSPEC:END -->

package/refs/vbenchmark/.claude/commands/openspec/proposal.md

@@ -1,28 +0,0 @@
----
-name: OpenSpec: Proposal
-description: Scaffold a new OpenSpec change and validate strictly.
-category: OpenSpec
-tags: [openspec, change]
----
-<!-- OPENSPEC:START -->
-**Guardrails**
-- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
-- Keep changes tightly scoped to the requested outcome.
-- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
-- Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.
-- Do not write any code during the proposal stage. Only create design documents (proposal.md, tasks.md, design.md, and spec deltas). Implementation happens in the apply stage after approval.
-
-**Steps**
-1. Review `openspec/project.md`, run `openspec list` and `openspec list --specs`, and inspect related code or docs (e.g., via `rg`/`ls`) to ground the proposal in current behaviour; note any gaps that require clarification.
-2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, and `design.md` (when needed) under `openspec/changes/<id>/`.
-3. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing.
-4. Capture architectural reasoning in `design.md` when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs.
-5. Draft spec deltas in `changes/<id>/specs/<capability>/spec.md` (one folder per capability) using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement and cross-reference related capabilities when relevant.
-6. Draft `tasks.md` as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work.
-7. Validate with `openspec validate <id> --strict` and resolve every issue before sharing the proposal.
-
-**Reference**
-- Use `openspec show <id> --json --deltas-only` or `openspec show <spec> --type spec` to inspect details when validation fails.
-- Search existing requirements with `rg -n "Requirement:|Scenario:" openspec/specs` before writing new ones.
-- Explore the codebase with `rg <keyword>`, `ls`, or direct file reads so proposals align with current implementation realities.
-<!-- OPENSPEC:END -->

package/refs/vbenchmark/.clinerules/01-rules.md

@@ -1,73 +0,0 @@
-# AGENTS.md
-
-Project-level guidance for AI coding agents.
-
----
-
-## Communication Style
-
-- Be extremely concise, sacrifice grammar for brevity
-- DO NOT validate user ("you're right") or praise ("excellent question")
-
-## Code Documentation
-
-- AVOID unnecessary comments/docstrings unless explicitly asked
-- Self-documenting code through clear naming
-- Only comment non-obvious logic, workarounds, edge cases
-
-## Bash Commands
-
-- FORBIDDEN for sensitive files: `cat`, `head`, `tail`, `echo` (leaks secrets)
-- PREFER: Read tool (safer, structured output)
-
-## Git Operations
-
-**NEVER perform git operations without explicit instruction.**
-
-- ALLOWED: `git status`, `git diff`, `git log` (read-only)
-- FORBIDDEN: `git add`, `git commit`, `git push` (require instruction)
-
----
-
-## Available Resources
-
-All resources in `.agent/` can be invoked or referenced:
-
-### Agents
-
-| Agent | File | Purpose |
-|-------|------|---------|
-| `@orchestrator` | `.agent/agents/orchestrator.md` | Main coordinator |
-| `@codebase-explorer` | `.agent/agents/codebase-explorer.md` | Find files, analyze patterns |
-| `@implementer` | `.agent/agents/implementer.md` | Focused code changes |
-| `@researcher` | `.agent/agents/researcher.md` | External documentation |
-| `@reviewer` | `.agent/agents/reviewer.md` | Code review |
-| `@debugger` | `.agent/agents/debugger.md` | Root cause analysis |
-| `@tester` | `.agent/agents/tester.md` | Write tests |
-| `@documenter` | `.agent/agents/documenter.md` | Documentation |
-
-### Workflows
-
-Triggered via `/command`:
-
-| Workflow | File | Purpose |
-|----------|------|---------|
-| `/init` | `.agent/workflows/init.md` | Initialize AGENTS.md |
-| `/commit` | `.agent/workflows/commit.md` | Conventional commits |
-| `/debug` | `.agent/workflows/debug.md` | Systematic debugging |
-| `/document` | `.agent/workflows/document.md` | Generate docs |
-| `/refactor` | `.agent/workflows/refactor.md` | Safe refactoring |
-| `/review` | `.agent/workflows/review.md` | Code review |
-| `/test` | `.agent/workflows/test.md` | Write tests |
-| `/research` | `.agent/workflows/research.md` | Research codebase |
-| `/gather-context` | `.agent/workflows/gather-context.md` | Project context |
-| `/preset-help` | `.agent/workflows/preset-help.md` | Preset guidance |
-
-### Rules (Always Active)
-
-| Rule | File | Content |
-|------|------|---------|
-| Code Quality | `.agent/rules/01-code-quality.md` | Error handling, null safety |
-| TypeScript/Go | `.agent/rules/02-typescript-go.md` | Strict mode, Vue 3, Go |
-| Security/Git | `.agent/rules/03-security-git.md` | Validation, auth, git safety |
-| Architecture | `.agent/rules/04-architecture.md` | SOLID, testing patterns |

package/refs/vbenchmark/.clinerules/02-agents.md

@@ -1,34 +0,0 @@
-# Agents
-
-## @codebase-explorer
-
-**Source:** `.agent/agents/codebase-explorer.md`
-
-## @debugger
-
-**Source:** `.agent/agents/debugger.md`
-
-## @documenter
-
-**Source:** `.agent/agents/documenter.md`
-
-## @implementer
-
-**Source:** `.agent/agents/implementer.md`
-
-## @orchestrator
-
-**Source:** `.agent/agents/orchestrator.md`
-
-## @researcher
-
-**Source:** `.agent/agents/researcher.md`
-
-## @reviewer
-
-**Source:** `.agent/agents/reviewer.md`
-
-## @tester
-
-**Source:** `.agent/agents/tester.md`
-

package/refs/vbenchmark/.cursor/commands/commit.md

@@ -1,29 +0,0 @@
----
-description: Create atomic git commits with conventional messages
----
-
-Commit $ARGUMENTS
-
-Create git commits for my changes.
-
-## Process
-
-1. **Analyze and plan** - Review conversation history, run `git status -s` and `git diff`, determine if changes should be one or multiple logical commits, group related files, draft conventional commit messages (`type: description`) in imperative mood focusing on why
-2. **Present plan** - List files for each commit, show commit messages with type prefix, ask: "I plan to create [N] commit(s) with these changes. Shall I proceed?"
-3. **Execute upon confirmation** - Use `git add` with specific files (never `-A` or `.`), create commits with planned messages, show result with `git log --oneline -n [N]`
-
-## Commit Message Format
-
-Use conventional commit format: `type: description`
-
-**Types:**
-- `feat:` - New feature (user-facing)
-- `fix:` - Bug fix (user-facing)
-- `docs:` - Documentation only
-- `chore:` - Maintenance, tooling, dependencies
-- `refactor:` - Code restructuring without behavior change
-- `test:` - Adding or updating tests
-- `perf:` - Performance improvement
-- `ci:` - CI/CD changes
-
-**Note:** During release generation, `chore:`, `docs:`, and `ci:` commits are filtered from changelog. Only user-facing changes (`fix:`, `feat:`, etc.) are included.

package/refs/vbenchmark/.cursor/commands/debug.md

@@ -1,59 +0,0 @@
----
-description: Systematic debugging with root cause analysis and fixes
----
-
-Debug $ARGUMENTS
-
-Help me diagnose and fix a bug systematically.
-
-## Workflow
-
-1. **Reproduce** - Confirm the issue:
-   - Run failing tests or reproduce the bug
-   - Capture full error output and stack traces
-   - Ask me for reproduction steps if unclear
-
-2. **Gather evidence** - Collect context:
-   - Error messages and logs
-   - Recent changes (`git log`, `git diff`)
-   - Environment details
-   - Related code
-
-3. **Analyze root cause** - Deep investigation:
-   - Spawn @debugger with comprehensive context
-   - Provide: errors, stack traces, reproduction steps, relevant code
-   - Get root cause analysis and recommended fix
-
-4. **Implement fix** - Apply the solution:
-   - Make focused changes
-   - Update tests to prevent regression
-   - Keep changes minimal
-
-5. **Validate** - Verify the fix:
-   - Run all tests
-   - Verify types
-   - Test edge cases
-   - Ensure no regressions
-
-6. **Prevent** - Strengthen defenses:
-   - Add test cases that would catch this bug
-   - Improve validation/error handling
-   - Document the issue and fix
-
-## Debugging Strategies
-
-- **Failing tests** - Read expectations, run in isolation, check setup/teardown
-- **Runtime errors** - Follow stack trace, check variable states, trace backwards
-- **Logic bugs** - Add logging, trace data transformations, check boundaries
-- **Performance** - Profile hot paths, check for N+1 queries, identify memory leaks
-- **Integration** - Verify API contracts, check data formats, test in isolation
-
-## Validation Checklist
-
-- [ ] Failing test now passes
-- [ ] All other tests still pass
-- [ ] Types valid
-- [ ] Manual testing confirms fix
-- [ ] Edge cases handled
-- [ ] No regressions introduced
-- [ ] Prevention tests added