mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-02-28 09:23:08 +08:00
feat: add injection preview functionality and enhance specs management
- Implemented injection preview feature in InjectionControlTab with file listing and content preview. - Added new API endpoint for fetching injection preview data. - Introduced content length caching for performance optimization. - Enhanced spec loading to support category filtering. - Updated localization files for new features and terms. - Created new personal and project specs for coding style and architecture constraints. - Improved CLI options for category selection in spec commands.
This commit is contained in:
27
.ccw/personal/coding-style.md
Normal file
27
.ccw/personal/coding-style.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "Personal Coding Style"
|
||||
dimension: personal
|
||||
category: general
|
||||
keywords:
|
||||
- style
|
||||
- preference
|
||||
readMode: optional
|
||||
priority: medium
|
||||
---
|
||||
|
||||
# Personal Coding Style
|
||||
|
||||
## Preferences
|
||||
|
||||
- Describe your preferred coding style here
|
||||
- Example: verbose variable names vs terse, functional vs imperative
|
||||
|
||||
## Patterns I Prefer
|
||||
|
||||
- List patterns you reach for most often
|
||||
- Example: builder pattern, factory functions, tagged unions
|
||||
|
||||
## Things I Avoid
|
||||
|
||||
- List anti-patterns or approaches you dislike
|
||||
- Example: deep inheritance hierarchies, magic strings
|
||||
25
.ccw/personal/tool-preferences.md
Normal file
25
.ccw/personal/tool-preferences.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "Tool Preferences"
|
||||
dimension: personal
|
||||
category: general
|
||||
keywords:
|
||||
- tool
|
||||
- cli
|
||||
- editor
|
||||
readMode: optional
|
||||
priority: low
|
||||
---
|
||||
|
||||
# Tool Preferences
|
||||
|
||||
## Editor
|
||||
|
||||
- Preferred editor and key extensions/plugins
|
||||
|
||||
## CLI Tools
|
||||
|
||||
- Preferred shell, package manager, build tools
|
||||
|
||||
## Debugging
|
||||
|
||||
- Preferred debugging approach and tools
|
||||
32
.ccw/specs/architecture-constraints.md
Normal file
32
.ccw/specs/architecture-constraints.md
Normal file
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: "Architecture Constraints"
|
||||
dimension: specs
|
||||
category: planning
|
||||
keywords:
|
||||
- architecture
|
||||
- module
|
||||
- layer
|
||||
- pattern
|
||||
readMode: required
|
||||
priority: high
|
||||
---
|
||||
|
||||
# Architecture Constraints
|
||||
|
||||
## Module Boundaries
|
||||
|
||||
- Each module owns its data and exposes a public API
|
||||
- No circular dependencies between modules
|
||||
- Shared utilities live in a dedicated shared layer
|
||||
|
||||
## Layer Separation
|
||||
|
||||
- Presentation layer must not import data layer directly
|
||||
- Business logic must be independent of framework specifics
|
||||
- Configuration must be externalized, not hardcoded
|
||||
|
||||
## Dependency Rules
|
||||
|
||||
- External dependencies require justification
|
||||
- Prefer standard library when available
|
||||
- Pin dependency versions for reproducibility
|
||||
38
.ccw/specs/coding-conventions.md
Normal file
38
.ccw/specs/coding-conventions.md
Normal file
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: "Coding Conventions"
|
||||
dimension: specs
|
||||
category: general
|
||||
keywords:
|
||||
- typescript
|
||||
- naming
|
||||
- style
|
||||
- convention
|
||||
readMode: required
|
||||
priority: high
|
||||
---
|
||||
|
||||
# Coding Conventions
|
||||
|
||||
## Naming
|
||||
|
||||
- Use camelCase for variables and functions
|
||||
- Use PascalCase for classes and interfaces
|
||||
- Use UPPER_SNAKE_CASE for constants
|
||||
|
||||
## Formatting
|
||||
|
||||
- 2-space indentation
|
||||
- Single quotes for strings
|
||||
- Trailing commas in multi-line constructs
|
||||
|
||||
## Patterns
|
||||
|
||||
- Prefer composition over inheritance
|
||||
- Use early returns to reduce nesting
|
||||
- Keep functions under 30 lines when practical
|
||||
|
||||
## Error Handling
|
||||
|
||||
- Always handle errors explicitly
|
||||
- Prefer typed errors over generic catch-all
|
||||
- Log errors with sufficient context
|
||||
Reference in New Issue
Block a user