@fifine/aim-studio 0.0.4 → 0.0.8

package/dist/templates/markdown/spec/cli/options-flags.md.txt

@@ -1,71 +0,0 @@
-# CLI Options & Flags
-
-> How command-line options and flags are defined.
-
----
-
-## Overview
-
-Document your CLI's options, flags, and environment variables.
-
----
-
-## Global Options
-
-| Option | Alias | Description | Default |
-|--------|-------|-------------|---------|
-| `--help` | `-h` | Show help | - |
-| `--version` | `-v` | Show version | - |
-| `--verbose` | - | Enable verbose output | `false` |
-
----
-
-## Environment Variables
-
-| Variable | Description | Default |
-|----------|-------------|---------|
-| `AIM_HOME` | AIM Studio home directory | `~/.aim-studio` |
-| `AIM_CONFIG` | Config file path | `~/.aim-studio/config.json` |
-
----
-
-## Command-Specific Options
-
-### init Command
-
-```bash
-aim init -u username --template react
-```
-
-| Option | Alias | Description |
-|--------|-------|-------------|
-| `--user` | `-u` | Developer username |
-| `--template` | - | Template to use |
-| `--force` | - | Overwrite existing files |
-
----
-
-## Patterns
-
-### Option Definition
-
-```typescript
-// Example: using commander.js
-program
-  .option('-u, --user <name>', 'Developer username')
-  .option('-t, --template <template>', 'Template name')
-  .option('-f, --force', 'Overwrite existing files');
-```
-
----
-
-## Anti-Patterns
-
-- ❌ Too many required options
-- ❌ Inconsistent option names (`--user` vs `--username`)
-
----
-
-## Add Your Examples
-
-Replace with your actual option definitions.

package/dist/templates/markdown/spec/cli/output-formatting.md.txt

@@ -1,93 +0,0 @@
-# CLI Output Formatting
-
-> How the CLI formats and presents output to users.
-
----
-
-## Overview
-
-Document your CLI's output conventions including colors, formatting, and user feedback.
-
----
-
-## Output Types
-
-| Type | Use Case |
-|------|----------|
-| `console.log` | Normal output, confirmations |
-| `console.error` | Errors, warnings |
-| `chalk` | Colored output for emphasis |
-
----
-
-## Color Conventions
-
-| Color | Usage |
-|-------|-------|
-| `cyan` | Primary information, headers |
-| `green` | Success messages, confirmations |
-| `yellow` | Warnings |
-| `red` | Errors |
-| `gray` | Secondary information |
-
----
-
-## Example Output
-
-### Success
-
-```
-✅ Project initialized successfully!
-```
-
-### Error
-
-```
-❌ Error: Directory already exists
-   Use --force to overwrite
-```
-
-### Progress
-
-```
-📦 Downloading template...
-   345.2 KB / 345.2 KB
-```
-
----
-
-## Patterns
-
-### Using Chalk
-
-```typescript
-import chalk from 'chalk';
-
-console.log(chalk.green('✓ ') + 'Success message');
-console.log(chalk.red('✗ ') + 'Error message');
-console.log(chalk.cyan('ℹ ') + 'Info message');
-```
-
-### Progress Indicators
-
-```typescript
-// Using ora for spinners
-import ora from 'ora';
-
-const spinner = ora('Loading...').start();
-spinner.succeed('Done!');
-```
-
----
-
-## Anti-Patterns
-
-- ❌ No error messages
-- ❌ Inconsistent colors
-- ❌ Too much output (noise)
-
----
-
-## Add Your Examples
-
-Replace with your actual output patterns.

package/dist/templates/markdown/spec/frontend/component-guidelines.md.txt

@@ -1,59 +0,0 @@
-# Component Guidelines
-
-> How components are built in this project.
-
----
-
-## Overview
-
-<!--
-Document your project's component conventions here.
-
-Questions to answer:
-- What component patterns do you use?
-- How are props defined?
-- How do you handle composition?
-- What accessibility standards apply?
--->
-
-(To be filled by the team)
-
----
-
-## Component Structure
-
-<!-- Standard structure of a component file -->
-
-(To be filled by the team)
-
----
-
-## Props Conventions
-
-<!-- How props should be defined and typed -->
-
-(To be filled by the team)
-
----
-
-## Styling Patterns
-
-<!-- How styles are applied (CSS modules, styled-components, Tailwind, etc.) -->
-
-(To be filled by the team)
-
----
-
-## Accessibility
-
-<!-- A11y requirements and patterns -->
-
-(To be filled by the team)
-
----
-
-## Common Mistakes
-
-<!-- Component-related mistakes your team has made -->
-
-(To be filled by the team)

package/dist/templates/markdown/spec/frontend/directory-structure.md.txt

@@ -1,54 +0,0 @@
-# Directory Structure
-
-> How frontend code is organized in this project.
-
----
-
-## Overview
-
-<!--
-Document your project's frontend directory structure here.
-
-Questions to answer:
-- Where do components live?
-- How are features/modules organized?
-- Where are shared utilities?
-- How are assets organized?
--->
-
-(To be filled by the team)
-
----
-
-## Directory Layout
-
-```
-<!-- Replace with your actual structure -->
-src/
-├── ...
-└── ...
-```
-
----
-
-## Module Organization
-
-<!-- How should new features be organized? -->
-
-(To be filled by the team)
-
----
-
-## Naming Conventions
-
-<!-- File and folder naming rules -->
-
-(To be filled by the team)
-
----
-
-## Examples
-
-<!-- Link to well-organized modules as examples -->
-
-(To be filled by the team)

package/dist/templates/markdown/spec/frontend/hook-guidelines.md.txt

@@ -1,51 +0,0 @@
-# Hook Guidelines
-
-> How hooks are used in this project.
-
----
-
-## Overview
-
-<!--
-Document your project's hook conventions here.
-
-Questions to answer:
-- What custom hooks do you have?
-- How do you handle data fetching?
-- What are the naming conventions?
-- How do you share stateful logic?
--->
-
-(To be filled by the team)
-
----
-
-## Custom Hook Patterns
-
-<!-- How to create and structure custom hooks -->
-
-(To be filled by the team)
-
----
-
-## Data Fetching
-
-<!-- How data fetching is handled (React Query, SWR, etc.) -->
-
-(To be filled by the team)
-
----
-
-## Naming Conventions
-
-<!-- Hook naming rules (use*, etc.) -->
-
-(To be filled by the team)
-
----
-
-## Common Mistakes
-
-<!-- Hook-related mistakes your team has made -->
-
-(To be filled by the team)

package/dist/templates/markdown/spec/frontend/index.md.txt

@@ -1,39 +0,0 @@
-# Frontend Development Guidelines
-
-> Best practices for frontend development in this project.
-
----
-
-## Overview
-
-This directory contains guidelines for frontend development. Fill in each file with your project's specific conventions.
-
----
-
-## Guidelines Index
-
-| Guide | Description | Status |
-|-------|-------------|--------|
-| [Directory Structure](./directory-structure.md) | Module organization and file layout | To fill |
-| [Component Guidelines](./component-guidelines.md) | Component patterns, props, composition | To fill |
-| [Hook Guidelines](./hook-guidelines.md) | Custom hooks, data fetching patterns | To fill |
-| [State Management](./state-management.md) | Local state, global state, server state | To fill |
-| [Quality Guidelines](./quality-guidelines.md) | Code standards, forbidden patterns | To fill |
-| [Type Safety](./type-safety.md) | Type patterns, validation | To fill |
-
----
-
-## How to Fill These Guidelines
-
-For each guideline file:
-
-1. Document your project's **actual conventions** (not ideals)
-2. Include **code examples** from your codebase
-3. List **forbidden patterns** and why
-4. Add **common mistakes** your team has made
-
-The goal is to help AI assistants and new team members understand how YOUR project works.
-
----
-
-**Language**: All documentation should be written in **English**.

package/dist/templates/markdown/spec/frontend/quality-guidelines.md.txt

@@ -1,51 +0,0 @@
-# Quality Guidelines
-
-> Code quality standards for frontend development.
-
----
-
-## Overview
-
-<!--
-Document your project's quality standards here.
-
-Questions to answer:
-- What patterns are forbidden?
-- What linting rules do you enforce?
-- What are your testing requirements?
-- What code review standards apply?
--->
-
-(To be filled by the team)
-
----
-
-## Forbidden Patterns
-
-<!-- Patterns that should never be used and why -->
-
-(To be filled by the team)
-
----
-
-## Required Patterns
-
-<!-- Patterns that must always be used -->
-
-(To be filled by the team)
-
----
-
-## Testing Requirements
-
-<!-- What level of testing is expected -->
-
-(To be filled by the team)
-
----
-
-## Code Review Checklist
-
-<!-- What reviewers should check -->
-
-(To be filled by the team)

package/dist/templates/markdown/spec/frontend/state-management.md.txt

@@ -1,51 +0,0 @@
-# State Management
-
-> How state is managed in this project.
-
----
-
-## Overview
-
-<!--
-Document your project's state management conventions here.
-
-Questions to answer:
-- What state management solution do you use?
-- How is local vs global state decided?
-- How do you handle server state?
-- What are the patterns for derived state?
--->
-
-(To be filled by the team)
-
----
-
-## State Categories
-
-<!-- Local state, global state, server state, URL state -->
-
-(To be filled by the team)
-
----
-
-## When to Use Global State
-
-<!-- Criteria for promoting state to global -->
-
-(To be filled by the team)
-
----
-
-## Server State
-
-<!-- How server data is cached and synchronized -->
-
-(To be filled by the team)
-
----
-
-## Common Mistakes
-
-<!-- State management mistakes your team has made -->
-
-(To be filled by the team)

package/dist/templates/markdown/spec/frontend/type-safety.md.txt

@@ -1,51 +0,0 @@
-# Type Safety
-
-> Type safety patterns in this project.
-
----
-
-## Overview
-
-<!--
-Document your project's type safety conventions here.
-
-Questions to answer:
-- What type system do you use?
-- How are types organized?
-- What validation library do you use?
-- How do you handle type inference?
--->
-
-(To be filled by the team)
-
----
-
-## Type Organization
-
-<!-- Where types are defined, shared types vs local types -->
-
-(To be filled by the team)
-
----
-
-## Validation
-
-<!-- Runtime validation patterns (Zod, Yup, io-ts, etc.) -->
-
-(To be filled by the team)
-
----
-
-## Common Patterns
-
-<!-- Type utilities, generics, type guards -->
-
-(To be filled by the team)
-
----
-
-## Forbidden Patterns
-
-<!-- any, type assertions, etc. -->
-
-(To be filled by the team)

package/dist/templates/markdown/spec/guides/code-reuse-thinking-guide.md

@@ -1,118 +0,0 @@
-# Code Reuse Thinking Guide
-
-> **Purpose**: Stop and think before creating new code - does it already exist?
-
----
-
-## The Problem
-
-**Duplicated code is the #1 source of inconsistency bugs.**
-
-When you copy-paste or rewrite existing logic:
-- Bug fixes don't propagate
-- Behavior diverges over time
-- Codebase becomes harder to understand
-
----
-
-## Before Writing New Code
-
-### Step 1: Search First
-
-```bash
-# Search for similar function names
-grep -r "functionName" .
-
-# Search for similar logic
-grep -r "keyword" .
-```
-
-### Step 2: Ask These Questions
-
-| Question | If Yes... |
-|----------|-----------|
-| Does a similar function exist? | Use or extend it |
-| Is this pattern used elsewhere? | Follow the existing pattern |
-| Could this be a shared utility? | Create it in the right place |
-| Am I copying code from another file? | **STOP** - extract to shared |
-
----
-
-## Common Duplication Patterns
-
-### Pattern 1: Copy-Paste Functions
-
-**Bad**: Copying a validation function to another file
-
-**Good**: Extract to shared utilities, import where needed
-
-### Pattern 2: Similar Components
-
-**Bad**: Creating a new component that's 80% similar to existing
-
-**Good**: Extend existing component with props/variants
-
-### Pattern 3: Repeated Constants
-
-**Bad**: Defining the same constant in multiple files
-
-**Good**: Single source of truth, import everywhere
-
----
-
-## When to Abstract
-
-**Abstract when**:
-- Same code appears 3+ times
-- Logic is complex enough to have bugs
-- Multiple people might need this
-
-**Don't abstract when**:
-- Only used once
-- Trivial one-liner
-- Abstraction would be more complex than duplication
-
----
-
-## After Batch Modifications
-
-When you've made similar changes to multiple files:
-
-1. **Review**: Did you catch all instances?
-2. **Search**: Run grep to find any missed
-3. **Consider**: Should this be abstracted?
-
----
-
-## Checklist Before Commit
-
-- [ ] Searched for existing similar code
-- [ ] No copy-pasted logic that should be shared
-- [ ] Constants defined in one place
-- [ ] Similar patterns follow same structure
-
----
-
-## Template File Registration (Trellis-specific)
-
-When adding new files to `src/templates/trellis/scripts/`:
-
-**CRITICAL**: New script files must be registered in THREE places:
-
-1. **`src/templates/trellis/index.ts`**:
-   - Add `export const xxxScript = readTemplate("scripts/path/file.py");`
-   - Add to `getAllScripts()` Map
-
-2. **`src/commands/update.ts`**:
-   - Add to import statement
-   - Add to `collectTemplateFiles()` Map
-
-**Why this matters**: Without registration, `trellis update` won't sync the file to user projects. Bug fixes and features won't propagate.
-
-### Quick Checklist for New Scripts
-
-```bash
-# After adding a new .py file, verify:
-grep -l "newFileName" src/templates/trellis/index.ts  # Should match
-grep -l "newFileName" src/commands/update.ts          # Should match
-```