├── .claude ├── commands │ ├── .keep │ ├── 01_brainstorm-feature.md │ ├── 02_feature-proposal.md │ ├── 03_feature-to-prd.md │ ├── 04_feature-planning.md │ ├── 05_implement.md │ ├── 05_implement_v2.md │ ├── add-react-feature.md │ ├── create-command.md │ ├── e2e-mcp-test.md │ ├── generate-react-app.md │ ├── implement-next.md │ ├── mode-baseline.md │ ├── mode-init.md │ ├── mode-test.md │ ├── mode-update.md │ ├── root_cause.md │ └── task_ui.md └── settings.local.json ├── .gitignore ├── .npmignore ├── .secretlintrc.json ├── .serena ├── cache │ └── document_symbols_cache_v20-05-25.pkl ├── memories │ ├── code_style_conventions.md │ ├── codebase_structure.md │ ├── development_guidelines.md │ ├── project_overview.md │ ├── suggested_commands.md │ ├── task_completion_checklist.md │ └── tech_stack.md └── project.yml ├── .tasks ├── .config │ └── project.json ├── .modes │ ├── design │ │ ├── area │ │ │ └── core.md │ │ ├── base.md │ │ └── trd.md │ ├── exploration │ │ ├── area │ │ │ └── core.md │ │ └── base.md │ ├── guidance │ │ ├── architecture-patterns.md │ │ ├── development-principles.md │ │ ├── frontend-tools.md │ │ ├── project-setup.md │ │ ├── react-patterns.md │ │ └── ui-research.md │ ├── implementation │ │ ├── area │ │ │ ├── cli.md │ │ │ ├── core.md │ │ │ ├── mcp.md │ │ │ └── ui.md │ │ ├── autonomous.md │ │ ├── base.md │ │ ├── code_review.md │ │ └── parent.md │ ├── meta │ │ └── base.md │ ├── orchestration │ │ ├── autonomous.md │ │ └── base.md │ └── planning │ │ ├── README.md │ │ └── base.md └── .templates │ ├── 01_feature.md │ ├── 02_bug.md │ ├── 03_chore.md │ ├── 04_documentation.md │ ├── 05_test.md │ └── 06_spike.md ├── CHANGELOG.md ├── CLAUDE.md ├── README.md ├── auto ├── biome.json ├── channelcoder-doc ├── README.md ├── documentation │ ├── README.md │ ├── guides │ │ ├── docker-mode.md │ │ ├── error-handling.md │ │ ├── session-management.md │ │ ├── stream-parser.md │ │ ├── templates.md │ │ └── worktree-mode.md │ └── reference │ │ ├── api.md │ │ └── cli.md ├── guides │ ├── docker-mode.md │ ├── error-handling.md │ ├── session-management.md │ ├── stream-parser.md │ ├── templates.md │ └── worktree-mode.md └── reference │ ├── README.md │ ├── api.md │ ├── cli.md │ ├── documentation │ ├── README.md │ ├── guides │ │ ├── docker-mode.md │ │ ├── error-handling.md │ │ ├── session-management.md │ │ ├── stream-parser.md │ │ ├── templates.md │ │ └── worktree-mode.md │ └── reference │ │ ├── api.md │ │ └── cli.md │ ├── guides │ ├── docker-mode.md │ ├── error-handling.md │ ├── session-management.md │ ├── stream-parser.md │ ├── templates.md │ └── worktree-mode.md │ └── reference │ ├── api.md │ └── cli.md ├── dispatch ├── docs ├── 00-overview │ ├── README.md │ ├── quick-start.md │ └── system-components.md ├── 01-concepts │ ├── areas.md │ ├── feedback-loops.md │ ├── mode-system.md │ ├── philosophy.md │ └── task-system.md ├── 02-architecture │ ├── code-organization.md │ ├── orchestration-architecture.md │ ├── service-architecture.md │ └── system-architecture.md ├── 03-guides │ ├── cli-workflows.md │ ├── mode-testing-guide.md │ ├── mode-testing-scenarios │ │ ├── README.md │ │ ├── nodejs-api-service.md │ │ ├── python-data-pipeline.md │ │ └── react-ecommerce.md │ └── storage-migration.md ├── 04-reference │ ├── cli.md │ └── storage-api.md ├── 99-archive │ ├── README.md │ ├── old-architecture │ │ ├── mcp-architecture.md │ │ ├── system-architecture.md │ │ └── worktree-dashboard-architecture.md │ ├── outdated-guides │ │ ├── WORKTREE-USAGE.md │ │ ├── development-modes-guide.md │ │ ├── implementation-priorities.md │ │ ├── orchestration-automation-vision.md │ │ └── websocket-claude.md │ └── v1-specs │ │ ├── ai-first-knowledge-system-vision.md │ │ ├── mode-system-design.md │ │ └── task-system-design.md ├── DEVELOPMENT.md ├── MCP_PROMPT_GUIDELINES.md ├── ROADMAP_IDEAS.md ├── SCOPECRAFT_STYLE_GUIDE.md ├── SCOPECRAFT_VS_CLAUDE_FLOW_COMPARISON.md ├── SCOPECRAFT_VS_CLAUDE_FLOW_DEEP_TECHNICAL_ANALYSIS.md ├── adr │ ├── 001-task-storage-migration.md │ ├── 002-search-architecture.md │ └── TEMPLATE.md ├── brainstorming │ ├── claude-code-flow-prompts-inspiration.md │ ├── document-editor-analysis.md │ ├── event-sourcing-architecture.md │ ├── otel-integration-for-event-sourcing.md │ └── task-orchestration-react-example.md ├── claude-commands-guide.md ├── code-quality.md ├── command-resources │ ├── README.md │ ├── implement-modes │ │ └── README.md │ └── planning-templates │ │ ├── README.md │ │ ├── brainstorming-guide.md │ │ ├── feature-planning.md │ │ ├── feature-prd.md │ │ ├── feature-proposal.md │ │ ├── prd-guide.md │ │ └── proposal-guide.md ├── components │ └── filter-panel-usage.md ├── design │ └── project-root-configuration.md ├── examples │ └── mermaid-diagrams.md ├── feature-development-workflow.md ├── fish-shell-cd-integration.md ├── ide-setup │ ├── claude-desktop-setup.md │ └── cursor-setup.md ├── marketing │ └── README-INTRODUCTION-DRAFT.md ├── mcp-configuration-commands.md ├── organizational-structure-guide.md ├── project-root-configuration-guide.md ├── prompt-generation-guide.md ├── specs │ ├── id-format.md │ ├── knowledge-system-design.md │ ├── metadata-architecture.md │ ├── mode-system-v2.md │ ├── scopecraft-vision.md │ └── task-system-v2-specification.md ├── troubleshooting-project-root.md └── worktree-api.md ├── orchestrate ├── orchestrate-auto ├── package.json ├── plan ├── scripts ├── README.md ├── check-path-usage.ts ├── code-check.ts ├── debug-mcp-phase.ts ├── finish-task.ts ├── fish-functions │ ├── README.md │ ├── tw-feat-start.fish │ └── tw-start.fish ├── fix-e2e-tests.ts ├── install-local.sh ├── migrate-to-centralized-storage.ts ├── migrate-workflow.ts ├── normalize-all-tasks.ts ├── prompts │ ├── release-analysis.md │ ├── systems │ │ ├── changelog-writer.md │ │ ├── release-manager.md │ │ └── version-analyzer.md │ ├── task-creator-enhanced.md │ └── tasks │ │ ├── changelog-generation.md │ │ └── version-analysis.md ├── release.ts ├── run-e2e-mcp-tests.sh ├── security-check.ts ├── setup-fish-integration.sh ├── test-fish-integration.sh ├── trace-mcp-comparison.ts ├── update-cli-version.ts └── utils │ └── claude-helper.ts ├── src ├── cli │ ├── cli.ts │ ├── commands.ts │ ├── commands │ │ ├── dispatch-commands.ts │ │ ├── env-commands.ts │ │ ├── plan-commands.ts │ │ └── work-commands.ts │ ├── entity-commands.ts │ ├── formatters.ts │ ├── init.ts │ └── validation-helpers.ts ├── core │ ├── config │ │ ├── configuration-manager.ts │ │ ├── index.ts │ │ └── types.ts │ ├── directory-utils.ts │ ├── environment │ │ ├── configuration-services.ts │ │ ├── index.ts │ │ ├── resolver-functions.ts │ │ ├── resolver.ts │ │ ├── types.ts │ │ ├── worktree-functions.ts │ │ ├── worktree-manager.ts │ │ └── worktree-path-resolver.ts │ ├── field-normalizers.ts │ ├── id-generator.ts │ ├── index.ts │ ├── metadata │ │ ├── default-schema.json │ │ ├── index.ts │ │ ├── normalizer-builder.ts │ │ ├── schema-service.ts │ │ └── types.ts │ ├── name-abbreviator.ts │ ├── parent-tasks.ts │ ├── paths │ │ ├── README.md │ │ ├── cache.ts │ │ ├── index.ts │ │ ├── migration.ts │ │ ├── path-resolver.ts │ │ ├── strategies.ts │ │ └── types.ts │ ├── project-config.ts │ ├── project-init.ts │ ├── search │ │ ├── __tests__ │ │ │ └── search-service.test.ts │ │ ├── index.ts │ │ ├── indexer.ts │ │ ├── orama-adapter.ts │ │ ├── search-service.ts │ │ └── types.ts │ ├── subtask-sequencing.ts │ ├── task-crud.ts │ ├── task-parser.ts │ ├── task-storage-path-encoder.ts │ ├── template-manager.ts │ ├── types.ts │ └── worktree │ │ ├── README.md │ │ ├── cache-manager.ts │ │ ├── index.ts │ │ ├── types.ts │ │ └── worktree-service.ts ├── integrations │ └── channelcoder │ │ ├── client.ts │ │ ├── constants.ts │ │ ├── helpers.ts │ │ ├── index.ts │ │ ├── monitoring.ts │ │ ├── session-storage.ts │ │ └── utils.ts ├── mcp │ ├── cli.ts │ ├── core-server.ts │ ├── handler-wrapper.ts │ ├── handlers.ts │ ├── handlers │ │ ├── index.ts │ │ ├── read-handlers.ts │ │ ├── shared │ │ │ ├── config-utils.ts │ │ │ ├── log-utils.ts │ │ │ ├── options-builders.ts │ │ │ ├── response-utils.ts │ │ │ ├── subtask-utils.ts │ │ │ └── validation-utils.ts │ │ └── write-handlers.ts │ ├── http-server.ts │ ├── output-schemas.ts │ ├── parameter-transformer.ts │ ├── schemas.ts │ ├── server.ts │ ├── stdio-cli.ts │ ├── stdio-server.ts │ ├── tools │ │ └── search-tools.ts │ ├── transformers.ts │ └── types.ts ├── observability │ └── logger.ts ├── scripts │ └── bun.d.ts └── templates │ ├── 01_feature.md │ ├── 02_bug.md │ ├── 03_chore.md │ ├── 04_documentation.md │ ├── 05_test.md │ ├── 06_spike.md │ ├── claude-commands │ ├── mode-init.md │ └── mode-update.md │ └── modes │ ├── design │ └── base.md │ ├── exploration │ └── base.md │ ├── guidance │ ├── development-principles.md │ └── project-setup.md │ ├── implementation │ ├── base.md │ └── code_review.md │ ├── meta │ └── base.md │ ├── orchestration │ ├── autonomous.md │ └── base.md │ └── planning │ └── base.md ├── task-create ├── tasks-ui ├── .cta.json ├── .gitignore ├── .storybook │ ├── main.ts │ ├── preview-head.html │ └── preview.tsx ├── .vscode │ └── settings.json ├── README.md ├── index.html ├── package.json ├── public │ ├── favicon.ico │ ├── logo192.png │ ├── logo512.png │ ├── manifest.json │ └── robots.txt ├── server.ts ├── server │ ├── autonomous-handlers.ts │ └── claude-session-handlers.ts ├── src │ ├── components │ │ ├── CommandCenter.stories.tsx │ │ ├── CommandCenter.tsx │ │ ├── CommandCenterWrapper.tsx │ │ ├── CommandPaletteWrapper.tsx │ │ ├── autonomous │ │ │ ├── AutonomousMonitor.tsx │ │ │ └── AutonomousSessionCard.tsx │ │ ├── claude │ │ │ ├── ClaudeAssistant.stories.tsx │ │ │ ├── ConnectionStatus.tsx │ │ │ ├── MessageStream.tsx │ │ │ ├── PromptForm.stories.tsx │ │ │ ├── PromptForm.tsx │ │ │ ├── SessionButton.css │ │ │ ├── SessionButton.tsx │ │ │ └── index.ts │ │ ├── layout │ │ │ ├── Header.tsx │ │ │ └── Toast.tsx │ │ ├── task-detail │ │ │ ├── MessageDisplay.tsx │ │ │ └── TaskContent.tsx │ │ ├── ui │ │ │ ├── breadcrumb.stories.tsx │ │ │ ├── breadcrumb.tsx │ │ │ ├── button.tsx │ │ │ ├── checkbox.tsx │ │ │ ├── command-palette.stories.tsx │ │ │ ├── command-palette.tsx │ │ │ ├── command.tsx │ │ │ ├── confirmation-dialog.stories.tsx │ │ │ ├── confirmation-dialog.tsx │ │ │ ├── dialog.tsx │ │ │ ├── filter-panel.stories.tsx │ │ │ ├── filter-panel.tsx │ │ │ ├── input.css │ │ │ ├── page-header.tsx │ │ │ ├── search-input.tsx │ │ │ ├── select.tsx │ │ │ └── visually-hidden.tsx │ │ └── v2 │ │ │ ├── ClaudeAgentButton.stories.tsx │ │ │ ├── ClaudeAgentButton.tsx │ │ │ ├── MetadataEditor │ │ │ ├── AreaInput.tsx │ │ │ ├── AssigneeInput.tsx │ │ │ ├── MetadataEditor.stories.tsx │ │ │ ├── MetadataEditor.tsx │ │ │ ├── PhaseDropdown.tsx │ │ │ ├── PriorityDropdown.tsx │ │ │ ├── StatusDropdown.tsx │ │ │ ├── TagInput.tsx │ │ │ ├── TextInput.tsx │ │ │ ├── TypeDropdown.tsx │ │ │ ├── WorkflowStateDropdown.tsx │ │ │ ├── index.ts │ │ │ └── useOptimisticUpdate.ts │ │ │ ├── ParentTaskCard-old.tsx │ │ │ ├── ParentTaskCard.stories.tsx │ │ │ ├── ParentTaskCard.tsx │ │ │ ├── ParentTaskListView.tsx │ │ │ ├── ParentTaskView.tsx │ │ │ ├── SectionEditor.stories.tsx │ │ │ ├── SectionEditor.tsx │ │ │ ├── SectionEditorDemo.stories.tsx │ │ │ ├── Sidebar.stories.tsx │ │ │ ├── Sidebar.tsx │ │ │ ├── SimpleTaskView.tsx │ │ │ ├── SubtaskList-old.tsx │ │ │ ├── SubtaskList.stories.tsx │ │ │ ├── SubtaskList.tsx │ │ │ ├── TaskManagementView.stories.tsx │ │ │ ├── TaskManagementView.tsx │ │ │ ├── TaskTable.stories.tsx │ │ │ ├── TaskTable.tsx │ │ │ ├── TaskTypeIcon.stories.tsx │ │ │ ├── TaskTypeIcon.tsx │ │ │ ├── V2Showcase.stories.tsx │ │ │ ├── WorkflowStateBadge.stories.tsx │ │ │ ├── WorkflowStateBadge.tsx │ │ │ └── index.ts │ ├── context │ │ ├── CommandCenterProvider.tsx │ │ ├── CommandPaletteProvider.tsx │ │ └── MockTaskProvider.tsx │ ├── hooks │ │ ├── useClaudeWebSocket.ts │ │ ├── useDebounce.ts │ │ ├── useMessageHandlers.ts │ │ ├── usePromptSender.ts │ │ ├── useTaskFilters.ts │ │ └── useTaskSearch.ts │ ├── lib │ │ ├── api │ │ │ ├── claude-sessions.ts │ │ │ ├── client.ts │ │ │ ├── hooks.ts │ │ │ └── mock-data-v2.ts │ │ ├── claude-message-handler.ts │ │ ├── icons.tsx │ │ ├── routes.ts │ │ ├── schema-client.ts │ │ ├── task-routing.ts │ │ ├── task-sections.ts │ │ ├── types.ts │ │ └── utils.ts │ ├── logo.svg │ ├── main.tsx │ ├── observability │ │ └── logger.ts │ ├── reportWebVitals.ts │ ├── routes │ │ ├── __root.tsx │ │ ├── assistant.tsx │ │ ├── autonomous.tsx │ │ ├── index.tsx │ │ ├── parents │ │ │ ├── $parentId.$subtaskId.tsx │ │ │ ├── $parentId.tsx │ │ │ └── index.tsx │ │ ├── tasks │ │ │ ├── $parentId │ │ │ │ └── $subtaskId.tsx │ │ │ ├── $taskId.tsx │ │ │ └── index.tsx │ │ └── workflow │ │ │ ├── $state.tsx │ │ │ └── index.tsx │ ├── stories │ │ ├── Button.stories.ts │ │ ├── Button.tsx │ │ ├── Configure.mdx │ │ ├── Header.stories.ts │ │ ├── Header.tsx │ │ ├── Page.stories.ts │ │ ├── Page.tsx │ │ ├── Test.stories.tsx │ │ ├── assets │ │ │ ├── accessibility.png │ │ │ ├── accessibility.svg │ │ │ ├── addon-library.png │ │ │ ├── assets.png │ │ │ ├── avif-test-image.avif │ │ │ ├── context.png │ │ │ ├── discord.svg │ │ │ ├── docs.png │ │ │ ├── figma-plugin.png │ │ │ ├── github.svg │ │ │ ├── share.png │ │ │ ├── styling.png │ │ │ ├── testing.png │ │ │ ├── theming.png │ │ │ ├── tutorials.svg │ │ │ └── youtube.svg │ │ ├── button.css │ │ ├── header.css │ │ └── page.css │ └── styles.css ├── streamClaude.ts ├── tailwind.config.js ├── tsconfig.json ├── vite.config.js └── websocket │ ├── claude-handler.ts │ ├── process-manager.ts │ ├── schemas.ts │ └── types.ts ├── test ├── TEST_SIMPLIFICATION.md ├── cli │ └── init-modes.test.ts ├── regression │ ├── dry-run-behavior.test.ts │ └── environment-resolution.test.ts └── unit │ ├── core │ ├── environment │ │ ├── configuration-services.test.ts │ │ ├── resolver.test.ts │ │ └── worktree-path-resolver.test.ts │ └── paths │ │ ├── path-resolver.test.ts │ │ └── strategies.test.ts │ └── mcp │ ├── phase-support.test.ts │ └── section-sanitization.test.ts ├── tsconfig.json └── work-docs ├── 01_desi-mgrton-strt-data-06C ├── migration-test-plan.md └── workflow-migration-trd.md ├── cret-mode-mgmt-scpcrft-06A ├── MODE_INIT_MAPPING.md ├── mode-creation-requirements.md └── mode-prompt-guide.md └── implmnt-cor-sea-sol-for-tas-06A └── search-service-trd.md /.claude/commands/.keep: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/scopecraft/command/9325ea949ac6369ec773a2e68a2a733bc52df9d9/.claude/commands/.keep -------------------------------------------------------------------------------- /.claude/commands/e2e-mcp-test.md: -------------------------------------------------------------------------------- 1 | Run the end-to-end tests for the MCP server using the STDIO transport. 2 | 3 | Follow the prompt-based test plan in `test/mcp/prompt-based-test-plan.md` and execute each test step with the appropriate MCP tool calls. 4 | 5 | Use the current date (YYYYMMDD format) for the test phase ID and document the results in a structured format. 6 | 7 | At the end, generate a comprehensive test report summarizing: 8 | 1. Total tests executed 9 | 2. Pass/fail count 10 | 3. Any issues discovered 11 | 4. Recommendations for fixes or improvements 12 | 13 | If specific tests are requested as arguments, only run those tests: $ARGUMENTS -------------------------------------------------------------------------------- /.claude/commands/mode-update.md: -------------------------------------------------------------------------------- 1 | # Update Mode: $ARGUMENTS 2 | 3 | Arguments: [modeType] [updateType] [description] 4 | - modeType: exploration, design, implementation, etc. 5 | - updateType: guidance, area-specific, new-variant 6 | - description: what you're updating 7 | 8 | 🚨 **CRITICAL SAFETY WARNING** 🚨 9 | This is a TEST command. Always save changes to `.tasks/.modes-test/` directory! 10 | NEVER modify `.tasks/.modes/` directly - that's the production directory! 11 | 12 | ## Your Task 13 | 14 | Based on `updateType`: 15 | 16 | ### If "guidance" - Add General Guidance 17 | 1. **Work in TEST directory**: 18 | ```bash 19 | ls .tasks/.modes-test/guidance/ 20 | ``` 21 | 22 | 2. **Create or update guidance file IN TEST DIR**: 23 | - `.tasks/.modes-test/guidance/{technology}-patterns.md` 24 | - `.tasks/.modes-test/guidance/{domain}-guidance.md` 25 | - `.tasks/.modes-test/guidance/{process}-workflows.md` 26 | 27 | ### If "area-specific" - Add Area Guidance 28 | 1. **Create area-specific mode file IN TEST DIR**: 29 | `.tasks/.modes-test/{modeType}/area/{area}.md` 30 | 31 | 2. **Focus on area-specific concerns** 32 | 33 | ### If "new-variant" - Create Mode Variant 34 | 1. **Create new variant file IN TEST DIR**: 35 | `.tasks/.modes-test/{modeType}/{variant-name}.md` 36 | 37 | ## Testing Workflow 38 | 39 | 1. **⚠️ Always work in `.modes-test/`** 40 | 2. **Copy existing mode if updating**: 41 | ```bash 42 | cp .tasks/.modes/{modeType}/base.md .tasks/.modes-test/{modeType}/base.md 43 | ``` 44 | 3. **Make your changes to the test version** 45 | 4. **Show diff for human review**: 46 | ```bash 47 | diff .tasks/.modes/{modeType}/base.md .tasks/.modes-test/{modeType}/base.md 48 | ``` 49 | 50 | ## Safety Reminders 51 | 52 | - ✅ Save to `.tasks/.modes-test/` 53 | - ❌ NEVER touch `.tasks/.modes/` 54 | - ✅ Create diffs for human review 55 | - ✅ Test with sample tasks 56 | - ✅ Document all changes 57 | 58 | ## Output Requirements 59 | 60 | 1. **Summary of changes made TO TEST DIRECTORY** 61 | 2. **Files created or modified IN .modes-test/** 62 | 3. **Diff showing what changed** 63 | 4. **Instructions for human to review and promote** 64 | 65 | Remember: We're building a safe testing environment. All changes need human approval before going to production! -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | dist/ 2 | .sessions 3 | .session/** 4 | .test-projects 5 | .claude/settings.local.json 6 | .claude/commands/temp-release-prompt-* 7 | .release/ 8 | test-*/ 9 | node_modules/ 10 | .DS_Store 11 | .ruru/ 12 | bun.lock 13 | mcp-server.log 14 | temp.md 15 | test/mcp/results/ 16 | .tmp/ 17 | .tasks/.autonomous-sessions/ 18 | # Note: .tasks is now tracked in git as it contains configuration 19 | 20 | # NPM package files 21 | *.tgz 22 | npm-debug.log* 23 | 24 | **/.claude/settings.local.json 25 | e2e_test/ 26 | tasks-ui/src/routeTree.gen.ts 27 | -------------------------------------------------------------------------------- /.npmignore: -------------------------------------------------------------------------------- 1 | # Source files 2 | src/ 3 | test/ 4 | scripts/ 5 | docs/ 6 | 7 | # Development files 8 | .git/ 9 | .github/ 10 | .gitignore 11 | .tasks/ 12 | .ruru/ 13 | .vscode/ 14 | .idea/ 15 | .DS_Store 16 | node_modules/ 17 | 18 | # Config files 19 | biome.json 20 | tsconfig.json 21 | jest.config.js 22 | .eslintrc.js 23 | .eslintignore 24 | 25 | # Temporary files 26 | *.log 27 | *.swp 28 | .temp/ 29 | tmp/ 30 | 31 | # Editor specific files 32 | .editorconfig 33 | 34 | # Worktree files 35 | .worktrees/ -------------------------------------------------------------------------------- /.secretlintrc.json: -------------------------------------------------------------------------------- 1 | { 2 | "rules": [ 3 | { 4 | "id": "@secretlint/secretlint-rule-preset-recommend" 5 | } 6 | ] 7 | } -------------------------------------------------------------------------------- /.serena/cache/document_symbols_cache_v20-05-25.pkl: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/scopecraft/command/9325ea949ac6369ec773a2e68a2a733bc52df9d9/.serena/cache/document_symbols_cache_v20-05-25.pkl -------------------------------------------------------------------------------- /.serena/memories/code_style_conventions.md: -------------------------------------------------------------------------------- 1 | # Code Style and Conventions 2 | 3 | ## TypeScript Conventions 4 | - **Strict mode** enabled 5 | - **No explicit any** - always use proper types 6 | - **No non-null assertions** - handle null/undefined properly 7 | - **No unused variables** 8 | - Use template literals instead of string concatenation 9 | - Interfaces for object shapes, types for unions/aliases 10 | 11 | ## Code Formatting (Biome) 12 | - **Indent**: 2 spaces 13 | - **Line width**: 100 characters 14 | - **Quotes**: Single quotes for strings 15 | - **Semicolons**: Always use semicolons 16 | - **Trailing commas**: ES5 style 17 | - **File organization**: Imports organized automatically 18 | 19 | ## Naming Conventions 20 | - **Files**: kebab-case (e.g., `task-parser.ts`) 21 | - **Classes**: PascalCase (e.g., `TaskManager`) 22 | - **Functions/Variables**: camelCase (e.g., `createTask`) 23 | - **Constants**: UPPER_SNAKE_CASE (e.g., `DEFAULT_WORKFLOW_FOLDERS`) 24 | - **Types/Interfaces**: PascalCase with descriptive names 25 | 26 | ## Module Structure 27 | - Export public API from index.ts files 28 | - Keep implementation details private 29 | - Use .js extensions in import statements (ESM) 30 | - Group related functionality in subdirectories 31 | 32 | ## Error Handling 33 | - Use custom error classes for domain errors 34 | - Always provide meaningful error messages 35 | - Handle edge cases explicitly 36 | - Return Result types for operations that can fail 37 | 38 | ## Comments 39 | - **DO NOT ADD COMMENTS** unless explicitly requested 40 | - Code should be self-documenting through clear naming 41 | - Use TypeScript types for documentation -------------------------------------------------------------------------------- /.serena/memories/codebase_structure.md: -------------------------------------------------------------------------------- 1 | # Codebase Structure 2 | 3 | ## Core Architecture 4 | 5 | ### `/src/core/` - Business Logic 6 | - **config/** - Configuration management 7 | - `configuration-manager.ts` - Runtime config handling 8 | - `types.ts` - Config type definitions 9 | - **metadata/** - Schema and normalization 10 | - `schema-service.ts` - Metadata schema management 11 | - `normalizer-builder.ts` - Field normalization 12 | - **worktree/** - Git worktree integration 13 | - `worktree-service.ts` - Worktree operations 14 | - `task-correlation-service.ts` - Task-worktree mapping 15 | - Core files: 16 | - `task-parser.ts` - MDTM file parsing/serialization 17 | - `task-crud.ts` - CRUD operations 18 | - `parent-tasks.ts` - Parent task management 19 | - `id-generator.ts` - Task ID generation 20 | - `directory-utils.ts` - File system operations 21 | 22 | ### `/src/cli/` - Command Line Interface 23 | - `cli.ts` - Entry point and command setup 24 | - `commands.ts` - Command implementations 25 | - `entity-commands.ts` - Entity-specific commands 26 | - `formatters.ts` - Output formatting 27 | - `validation-helpers.ts` - Input validation 28 | 29 | ### `/src/mcp/` - Model Context Protocol Server 30 | - `server.ts` - HTTP server setup 31 | - `stdio-server.ts` - STDIO transport 32 | - `handlers/` - Request handlers 33 | - `read-handlers.ts` - Query operations 34 | - `write-handlers.ts` - Mutation operations 35 | - `shared/` - Shared utilities 36 | - `schemas.ts` - Zod schemas for validation 37 | - `transformers.ts` - Data transformation 38 | 39 | ### `/tasks-ui/` - Web Interface 40 | - React-based dashboard 41 | - WebSocket support for real-time updates 42 | - Storybook for component development 43 | 44 | ### `/docs/` - Documentation 45 | - Architecture and design docs 46 | - Development guides 47 | - Style guides and conventions 48 | 49 | ### `/scripts/` - Development Scripts 50 | - `code-check.ts` - Quality checks 51 | - `release.ts` - Release automation 52 | - `task-worktree.ts` - Git worktree helpers 53 | 54 | ## Key Design Patterns 55 | 1. **Separation of Concerns**: Core logic separate from UI/transport 56 | 2. **Schema-First**: Zod schemas for validation 57 | 3. **Functional Core**: Pure functions in core module 58 | 4. **Type Safety**: Strict TypeScript throughout 59 | 5. **Modular Structure**: Clear module boundaries -------------------------------------------------------------------------------- /.serena/memories/development_guidelines.md: -------------------------------------------------------------------------------- 1 | # Development Guidelines 2 | 3 | ## Project-Specific Requirements 4 | 5 | ### Task Management Philosophy 6 | - **ALWAYS** use the CLI to manage tasks in this project (dogfooding) 7 | - Create tasks immediately when issues are discovered 8 | - Update task logs with significant changes 9 | - Mark tasks as "In Progress" when starting work 10 | - Use parent tasks for work with 3+ subtasks 11 | 12 | ### File Naming and IDs 13 | - Task IDs follow pattern: `title-abbreviation-monthsuffix` 14 | - Month suffixes use base-26 encoding (e.g., 06A = June, first iteration) 15 | - Workflow states: backlog/ → current/ → archive/ 16 | - Parent tasks contain subtasks as numbered files 17 | 18 | ### Testing Approach 19 | - Use Bun test framework 20 | - E2E tests for core functionality 21 | - Create test tasks with `test-` prefix or in TEST workflow 22 | - Run tests before major changes 23 | 24 | ### MCP Development 25 | - Follow Model Context Protocol specifications 26 | - Maintain compatibility with Claude Desktop and Cursor 27 | - Support both HTTP/SSE and STDIO transports 28 | - Keep request/response schemas in sync 29 | 30 | ### UI Development 31 | - Use Storybook for component development 32 | - Follow the Scopecraft design system 33 | - Maintain TypeScript types for all components 34 | - Keep API and UI in sync 35 | 36 | ## Best Practices 37 | 38 | ### Code Organization 39 | 1. Keep modules focused and cohesive 40 | 2. Export public API through index.ts 41 | 3. Use dependency injection where appropriate 42 | 4. Avoid circular dependencies 43 | 44 | ### Error Handling 45 | 1. Use custom error classes 46 | 2. Provide actionable error messages 47 | 3. Handle edge cases explicitly 48 | 4. Log errors appropriately 49 | 50 | ### Performance 51 | 1. Use streaming for large operations 52 | 2. Implement caching where beneficial 53 | 3. Avoid blocking operations 54 | 4. Profile before optimizing 55 | 56 | ### Security 57 | 1. Validate all inputs 58 | 2. Sanitize file paths 59 | 3. Use environment variables for secrets 60 | 4. Run security checks regularly 61 | 62 | ## Contribution Workflow 63 | 1. Create a task for your work 64 | 2. Mark task as "In Progress" 65 | 3. Make changes following style guide 66 | 4. Run `bun run code-check` 67 | 5. Update task log with changes 68 | 6. Create PR with meaningful description 69 | 7. Mark task as complete after merge -------------------------------------------------------------------------------- /.serena/memories/project_overview.md: -------------------------------------------------------------------------------- 1 | # Scopecraft Command Project Overview 2 | 3 | ## Purpose 4 | Scopecraft Command is a powerful command-line tool and MCP server for managing Markdown-Driven Task Management (MDTM) files. It helps organize tasks, features, and development workflows with a structured approach. 5 | 6 | ## Key Features 7 | - Workflow-based task organization (backlog → current → archive) 8 | - Parent tasks with subtask sequencing and parallel execution 9 | - Supports MDTM format with TOML/YAML frontmatter 10 | - Provides both CLI and MCP server interfaces 11 | - Works with any AI IDE (Cursor, Claude Desktop, etc.) 12 | - Multi-project support with easy switching 13 | - Automated project type detection 14 | 15 | ## Project Structure 16 | - `/src/core/` - Core business logic for task management 17 | - `/src/cli/` - Command-line interface implementation 18 | - `/src/mcp/` - Model Context Protocol server implementation 19 | - `/tasks-ui/` - Web UI for task management 20 | - `/docs/` - Comprehensive documentation 21 | - `/scripts/` - Development and utility scripts 22 | - `/test/` - Test files 23 | 24 | ## Development Philosophy 25 | The system is designed to be versatile: 26 | - Works both with and without Roo Commander 27 | - Provides direct CRUD operations without requiring LLM processing 28 | - Automatically detects project type and adapts accordingly 29 | - Dogfoods its own tools for task management -------------------------------------------------------------------------------- /.serena/memories/task_completion_checklist.md: -------------------------------------------------------------------------------- 1 | # Task Completion Checklist 2 | 3 | ## Before Committing Code 4 | 5 | ### 1. Run Code Quality Checks 6 | ```bash 7 | bun run code-check 8 | ``` 9 | This command will: 10 | - Auto-detect whether to check staged or changed files 11 | - Run Biome linting on the appropriate files 12 | - Run TypeScript type checking on the full project 13 | - Report results in a clear format 14 | 15 | Options: 16 | - `--staged`: Check only staged files 17 | - `--changed`: Check only changed files 18 | - `--all`: Check all files 19 | - `--format=json`: Output results in JSON format 20 | 21 | ### 2. Run Tests (if applicable) 22 | ```bash 23 | bun test 24 | ``` 25 | 26 | ### 3. Update Task Status 27 | When working on a task: 28 | ```bash 29 | # Mark task as complete when done 30 | bun run dev:cli task complete 31 | 32 | # Update the task log section with changes made 33 | bun run dev:cli task get --format full 34 | # Then manually edit to add log entry like: 35 | # - 2025-05-28: Implemented feature X 36 | ``` 37 | 38 | ### 4. Verify Build 39 | For distribution changes: 40 | ```bash 41 | bun run build 42 | ``` 43 | 44 | ## Important Notes 45 | - The build will FAIL if code-check doesn't pass 46 | - Always update task logs with significant changes 47 | - Use `bun run dev:cli` for immediate changes (no compilation needed) 48 | - Never commit without running code-check first -------------------------------------------------------------------------------- /.serena/memories/tech_stack.md: -------------------------------------------------------------------------------- 1 | # Tech Stack 2 | 3 | ## Languages & Runtime 4 | - **TypeScript** - Primary development language 5 | - **Bun** - JavaScript runtime and package manager (preferred) 6 | - **Node.js** - Supported runtime (16.0.0+) 7 | 8 | ## Core Dependencies 9 | - `@modelcontextprotocol/sdk` - MCP protocol implementation 10 | - `commander` - CLI framework 11 | - `express` - HTTP server for MCP and UI 12 | - `gray-matter` - YAML/TOML frontmatter parsing 13 | - `zod` - Schema validation 14 | - `simple-git` - Git operations for worktree features 15 | - `chalk` - Terminal styling 16 | 17 | ## Development Tools 18 | - **Biome** - Linting and formatting (replaces ESLint/Prettier) 19 | - **TypeScript** - Type checking with strict mode 20 | - **Bun Test** - Testing framework 21 | - **Storybook** - Component development and documentation 22 | 23 | ## Build Configuration 24 | - Target: ES2020 25 | - Module: NodeNext 26 | - Strict TypeScript enabled 27 | - Source maps generated 28 | - Declaration files generated 29 | 30 | ## Package Management 31 | - Primary: Bun (bun install) 32 | - Also supports: npm, yarn 33 | - Global installation supported -------------------------------------------------------------------------------- /.tasks/.config/project.json: -------------------------------------------------------------------------------- 1 | { 2 | "autoWorkflowTransitions": false 3 | } -------------------------------------------------------------------------------- /.tasks/.modes/design/area/core.md: -------------------------------------------------------------------------------- 1 | # Core Area - Design Mode 2 | 3 | ## Storage Architecture Constraints 4 | 5 | When designing core features: 6 | - Tasks must be stored in centralized location (`~/.scopecraft/projects/{encoded}/`) 7 | - All path resolution goes through `src/core/paths/path-resolver.ts` 8 | - Worktrees share storage by using main repository root 9 | - Templates and modes stay in repository (`.tasks/`) -------------------------------------------------------------------------------- /.tasks/.modes/design/base.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: design 3 | description: Create technical designs and architectural decisions 4 | --- 5 | 6 | 7 | 8 | 9 | 10 | You have a stake in this project's success. 11 | 12 | 13 | 14 | Create technical designs that balance quality with pragmatism. 15 | 16 | 17 | 18 | - Understand constraints first 19 | - Consider multiple options 20 | - Document trade-offs clearly 21 | - Plan for iteration 22 | 23 | 24 | 25 | 26 | 27 | 28 | Define problem → Explore solutions → Decide → Document 29 | 30 | 31 | 32 | 33 | Technical approach, trade-offs, implementation plan 34 | -------------------------------------------------------------------------------- /.tasks/.modes/exploration/area/core.md: -------------------------------------------------------------------------------- 1 | # Core Area - Exploration Mode 2 | 3 | ## Storage System Specifics 4 | 5 | When exploring storage-related code: 6 | - Path resolution is centralized in `src/core/paths/` 7 | - Tasks are stored outside the repository in `~/.scopecraft/projects/{encoded}/tasks/` 8 | - All worktrees share the same task storage 9 | - Use `createPathContext()` and `resolvePath()` for all path operations 10 | 11 | **IF** you need deep understanding of storage architecture: 12 | - `docs/02-architecture/system-architecture.md#storage-architecture` - Full architecture 13 | - `src/core/paths/README.md` - Path resolution implementation details -------------------------------------------------------------------------------- /.tasks/.modes/guidance/project-setup.md: -------------------------------------------------------------------------------- 1 | # Project Setup Guidance 2 | 3 | 4 | 5 | 6 | ## Project Structure 7 | Define your standard directory layout and file organization. 8 | 9 | ## Naming Conventions 10 | - Tasks: How to name task files and IDs 11 | - Modes: Mode naming patterns 12 | - Files: Code file naming standards 13 | 14 | ## Tool Configuration 15 | List standard tools and their configuration. 16 | 17 | ## Development Workflow 18 | How your team works with tasks and modes. -------------------------------------------------------------------------------- /.tasks/.modes/planning/README.md: -------------------------------------------------------------------------------- 1 | # Planning Mode 2 | 3 | Breaks down ideas and features into actionable tasks for the AI army. 4 | 5 | ## Philosophy 6 | 7 | One developer + AI army = Need smart task breakdown that: 8 | - Identifies what can be done in parallel 9 | - Knows when to explore vs implement 10 | - Creates review gates where human input matters 11 | - Keeps simple things simple 12 | 13 | ## Files 14 | 15 | ### base.md 16 | Entry point - takes a feature description and creates appropriate tasks. 17 | 18 | ### adaptive.md 19 | The brain - assesses complexity and generates the right task structure: 20 | - **Too vague?** → Creates a brainstorming task 21 | - **Simple?** → One comprehensive task 22 | - **Medium?** → Standard sequence of tasks 23 | - **Complex?** → Research + prototypes + review gates 24 | - **Huge?** → Multi-phase initiative 25 | 26 | ## Usage 27 | 28 | ```bash 29 | # Turn an idea into tasks 30 | channelcoder .tasks/.modes/planning/base.md \ 31 | -d feature_description="Add dark mode toggle" \ 32 | -d area="ui" 33 | 34 | # Or go directly to adaptive planning 35 | channelcoder .tasks/.modes/planning/adaptive.md \ 36 | -d feature_description="Build real-time collaboration" \ 37 | -d area="ui" 38 | ``` 39 | 40 | ## Examples 41 | 42 | **Simple**: "Add logout button" → One task with everything 43 | **Medium**: "Add OAuth login" → Research, design, implement, test 44 | **Complex**: "Real-time collab" → Multiple research paths, prototypes, iterative development -------------------------------------------------------------------------------- /.tasks/.templates/01_feature.md: -------------------------------------------------------------------------------- 1 | # << FEATURE TITLE >> 2 | 3 | ## Description 4 | **What is this feature?** 5 | - 6 | 7 | **Why is it needed?** 8 | - 9 | 10 | **Who will use it?** 11 | - 12 | 13 | ## Acceptance Criteria 14 | - [ ] 15 | - [ ] 16 | - [ ] 17 | 18 | ## Implementation Plan 19 | ### Technical Approach 20 | - 21 | 22 | ### Sub-tasks 23 | - [ ] 24 | - [ ] 25 | - [ ] 26 | 27 | ## Dependencies 28 | - 29 | 30 | ## Implementation Log 31 | _Keep track of what was implemented and when_ 32 | - 33 | 34 | ## Notes 35 | - -------------------------------------------------------------------------------- /.tasks/.templates/02_bug.md: -------------------------------------------------------------------------------- 1 | # << BUG SUMMARY >> 2 | 3 | ## Description 4 | **What is the problem?** 5 | - 6 | 7 | **When does it occur?** 8 | - 9 | 10 | **Who is affected?** 11 | - 12 | 13 | ## Steps to Reproduce 14 | 1. 15 | 2. 16 | 3. 17 | 18 | ## Expected vs Actual Behavior 19 | **Expected:** 20 | - 21 | 22 | **Actual:** 23 | - 24 | 25 | ## Environment 26 | - OS: 27 | - Version: 28 | - Browser (if applicable): 29 | 30 | ## Possible Solution 31 | - 32 | 33 | ## Implementation Log 34 | _Track fix attempts and results_ 35 | - 36 | 37 | ## Notes 38 | - -------------------------------------------------------------------------------- /.tasks/.templates/03_chore.md: -------------------------------------------------------------------------------- 1 | # << CHORE TITLE >> 2 | 3 | ## Description 4 | **What needs to be done?** 5 | - 6 | 7 | **Why is this necessary?** 8 | - 9 | 10 | ## Tasks 11 | - [ ] 12 | - [ ] 13 | - [ ] 14 | 15 | ## Definition of Done 16 | - [ ] 17 | - [ ] 18 | 19 | ## Implementation Log 20 | _Track what was done and when_ 21 | - 22 | 23 | ## Notes 24 | - -------------------------------------------------------------------------------- /.tasks/.templates/04_documentation.md: -------------------------------------------------------------------------------- 1 | # << DOCUMENTATION TITLE >> 2 | 3 | ## Purpose 4 | **What is being documented?** 5 | - 6 | 7 | **Who is the audience?** 8 | - 9 | 10 | ## Content Outline 11 | 1. 12 | 2. 13 | 3. 14 | 15 | ## Key Points to Cover 16 | - 17 | - 18 | - 19 | 20 | ## References 21 | - 22 | 23 | ## Writing Log 24 | _Track documentation progress_ 25 | - 26 | 27 | ## Notes 28 | - -------------------------------------------------------------------------------- /.tasks/.templates/05_test.md: -------------------------------------------------------------------------------- 1 | # << TEST TITLE >> 2 | 3 | ## Test Objective 4 | **What are we testing?** 5 | - 6 | 7 | **Why is this test important?** 8 | - 9 | 10 | ## Test Type 11 | - [ ] Unit Test 12 | - [ ] Integration Test 13 | - [ ] End-to-End Test 14 | - [ ] Performance Test 15 | - [ ] Other: 16 | 17 | ## Test Cases 18 | ### Test Case 1: 19 | **Given:** 20 | **When:** 21 | **Then:** 22 | 23 | ### Test Case 2: 24 | **Given:** 25 | **When:** 26 | **Then:** 27 | 28 | ## Test Data Requirements 29 | - 30 | 31 | ## Success Criteria 32 | - [ ] 33 | - [ ] 34 | 35 | ## Implementation Log 36 | _Track test development progress_ 37 | - 38 | 39 | ## Notes 40 | - -------------------------------------------------------------------------------- /.tasks/.templates/06_spike.md: -------------------------------------------------------------------------------- 1 | # << SPIKE/RESEARCH TITLE >> 2 | 3 | ## Research Question 4 | **What do we need to find out?** 5 | - 6 | 7 | **Why is this important?** 8 | - 9 | 10 | ## Timebox 11 | - Duration: 12 | 13 | ## Approach 14 | 1. 15 | 2. 16 | 3. 17 | 18 | ## Options to Evaluate 19 | ### Option A: 20 | **Pros:** 21 | - 22 | 23 | **Cons:** 24 | - 25 | 26 | ### Option B: 27 | **Pros:** 28 | - 29 | 30 | **Cons:** 31 | - 32 | 33 | ## Success Criteria 34 | - [ ] 35 | - [ ] 36 | 37 | ## Research Log 38 | _Track research activities and progress_ 39 | - 40 | 41 | ## Findings 42 | - 43 | 44 | ## Recommendation 45 | - 46 | 47 | ## Next Steps 48 | - -------------------------------------------------------------------------------- /auto: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | # Wrapper script for autonomous task execution 4 | # This delegates to the new dispatch command with auto mode 5 | 6 | # Check if we have at least one argument (taskId) 7 | if [ $# -eq 0 ]; then 8 | echo "Usage: ./auto [parentId]" 9 | echo " ./auto --help" 10 | exit 1 11 | fi 12 | 13 | # Handle help flag 14 | if [ "$1" = "--help" ] || [ "$1" = "-h" ]; then 15 | echo "Autonomous Task Executor" 16 | echo "" 17 | echo "Usage:" 18 | echo " ./auto [parentId] Execute a task autonomously" 19 | echo "" 20 | echo "Examples:" 21 | echo " # Execute a standalone task" 22 | echo " ./auto implement-auth-05A" 23 | echo "" 24 | echo " # Execute a subtask with parent context" 25 | echo " ./auto 02_implement-api-05B auth-feature-05A" 26 | exit 0 27 | fi 28 | 29 | # Execute using the new dispatch command with auto mode 30 | # The dispatch command will handle parentId if provided as part of task resolution 31 | exec bun run dev:cli dispatch "$1" --mode auto --exec tmux -------------------------------------------------------------------------------- /biome.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "https://biomejs.dev/schemas/1.9.4/schema.json", 3 | "organizeImports": { 4 | "enabled": true 5 | }, 6 | "linter": { 7 | "enabled": true, 8 | "rules": { 9 | "recommended": true, 10 | "complexity": { 11 | "noExcessiveCognitiveComplexity": "error" 12 | }, 13 | "correctness": { 14 | "noUnusedVariables": "error" 15 | }, 16 | "style": { 17 | "noNonNullAssertion": "error", 18 | "useTemplate": "error" 19 | }, 20 | "suspicious": { 21 | "noExplicitAny": "error" 22 | } 23 | } 24 | }, 25 | "formatter": { 26 | "enabled": true, 27 | "indentStyle": "space", 28 | "indentWidth": 2, 29 | "lineWidth": 100 30 | }, 31 | "javascript": { 32 | "formatter": { 33 | "quoteStyle": "single", 34 | "trailingCommas": "es5", 35 | "semicolons": "always" 36 | } 37 | }, 38 | "files": { 39 | "include": [ 40 | "src/**/*.ts", 41 | "test/**/*.ts", 42 | "test/**/*.js", 43 | "tasks-ui/src/**/*.ts", 44 | "tasks-ui/src/**/*.tsx" 45 | ], 46 | "ignore": ["dist", "node_modules", "**/*.d.ts", "tasks-ui/dist", "tasks-ui/node_modules"] 47 | }, 48 | "vcs": { 49 | "enabled": true, 50 | "clientKind": "git", 51 | "useIgnoreFile": true, 52 | "defaultBranch": "main" 53 | } 54 | } 55 | -------------------------------------------------------------------------------- /channelcoder-doc/README.md: -------------------------------------------------------------------------------- 1 | # ChannelCoder Documentation 2 | 3 | Welcome to the ChannelCoder documentation! This directory contains detailed guides for advanced features. 4 | 5 | ## Guides 6 | 7 | ### Advanced Features 8 | - [Docker Mode](./guides/docker-mode.md) - Run Claude in isolated Docker containers 9 | - [Git Worktree Mode](./guides/worktree-mode.md) - Parallel development workflows 10 | - [Session Management](./guides/session-management.md) - Multi-turn conversation handling 11 | - [Stream Parser SDK](./guides/stream-parser.md) - Parse and monitor streaming output 12 | 13 | ### Reference 14 | - [CLI Reference](./reference/cli.md) - Complete command-line interface documentation 15 | 16 | ## Quick Links 17 | 18 | - [Main README](../README.md) - Installation and quick start 19 | - [Examples](../examples/) - Working code examples 20 | - [API Documentation](./reference/api.md) - SDK API reference (coming soon) 21 | 22 | ## Contributing 23 | 24 | For internal architecture documentation and development notes, see the `/docs` directory. -------------------------------------------------------------------------------- /channelcoder-doc/documentation/README.md: -------------------------------------------------------------------------------- 1 | # ChannelCoder Documentation 2 | 3 | Welcome to the ChannelCoder documentation! This directory contains detailed guides for advanced features. 4 | 5 | ## Guides 6 | 7 | ### Advanced Features 8 | - [Docker Mode](./guides/docker-mode.md) - Run Claude in isolated Docker containers 9 | - [Git Worktree Mode](./guides/worktree-mode.md) - Parallel development workflows 10 | - [Session Management](./guides/session-management.md) - Multi-turn conversation handling 11 | - [Stream Parser SDK](./guides/stream-parser.md) - Parse and monitor streaming output 12 | 13 | ### Reference 14 | - [CLI Reference](./reference/cli.md) - Complete command-line interface documentation 15 | 16 | ## Quick Links 17 | 18 | - [Main README](../README.md) - Installation and quick start 19 | - [Examples](../examples/) - Working code examples 20 | - [API Documentation](./reference/api.md) - SDK API reference (coming soon) 21 | 22 | ## Contributing 23 | 24 | For internal architecture documentation and development notes, see the `/docs` directory. -------------------------------------------------------------------------------- /channelcoder-doc/reference/README.md: -------------------------------------------------------------------------------- 1 | # ChannelCoder Documentation 2 | 3 | Welcome to the ChannelCoder documentation! This directory contains detailed guides for advanced features. 4 | 5 | ## Guides 6 | 7 | ### Advanced Features 8 | - [Docker Mode](./guides/docker-mode.md) - Run Claude in isolated Docker containers 9 | - [Git Worktree Mode](./guides/worktree-mode.md) - Parallel development workflows 10 | - [Session Management](./guides/session-management.md) - Multi-turn conversation handling 11 | - [Stream Parser SDK](./guides/stream-parser.md) - Parse and monitor streaming output 12 | 13 | ### Reference 14 | - [CLI Reference](./reference/cli.md) - Complete command-line interface documentation 15 | 16 | ## Quick Links 17 | 18 | - [Main README](../README.md) - Installation and quick start 19 | - [Examples](../examples/) - Working code examples 20 | - [API Documentation](./reference/api.md) - SDK API reference (coming soon) 21 | 22 | ## Contributing 23 | 24 | For internal architecture documentation and development notes, see the `/docs` directory. -------------------------------------------------------------------------------- /channelcoder-doc/reference/documentation/README.md: -------------------------------------------------------------------------------- 1 | # ChannelCoder Documentation 2 | 3 | Welcome to the ChannelCoder documentation! This directory contains detailed guides for advanced features. 4 | 5 | ## Guides 6 | 7 | ### Advanced Features 8 | - [Docker Mode](./guides/docker-mode.md) - Run Claude in isolated Docker containers 9 | - [Git Worktree Mode](./guides/worktree-mode.md) - Parallel development workflows 10 | - [Session Management](./guides/session-management.md) - Multi-turn conversation handling 11 | - [Stream Parser SDK](./guides/stream-parser.md) - Parse and monitor streaming output 12 | 13 | ### Reference 14 | - [CLI Reference](./reference/cli.md) - Complete command-line interface documentation 15 | 16 | ## Quick Links 17 | 18 | - [Main README](../README.md) - Installation and quick start 19 | - [Examples](../examples/) - Working code examples 20 | - [API Documentation](./reference/api.md) - SDK API reference (coming soon) 21 | 22 | ## Contributing 23 | 24 | For internal architecture documentation and development notes, see the `/docs` directory. -------------------------------------------------------------------------------- /docs/99-archive/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Archived Documentation" 3 | description: "Historical documentation preserved for reference" 4 | version: "1.0" 5 | status: "archived" 6 | category: "archive" 7 | updated: "2025-01-07" 8 | authors: ["system"] 9 | --- 10 | 11 | # Archived Documentation 12 | 13 | This folder contains historical documentation that has been superseded by newer versions or represents early thinking that has evolved. These documents are preserved for: 14 | 15 | 1. **Historical Reference** - Understanding how the project evolved 16 | 2. **Recovery** - In case we need to revisit old ideas 17 | 3. **Learning** - Seeing what approaches didn't work and why 18 | 19 | ## Archive Structure 20 | 21 | ### v1-specs/ 22 | Original specifications that have been replaced by v2 versions: 23 | - `task-system-design.md` → Replaced by `task-system-v2-specification.md` 24 | - `mode-system-design.md` → Replaced by `mode-system-v2.md` 25 | - `ai-first-knowledge-system-vision.md` → Concept not fully implemented 26 | 27 | ### old-architecture/ 28 | Early architecture documents superseded by new structured docs: 29 | - `system-architecture.md` → Replaced by `/docs/02-architecture/system-architecture.md` 30 | - `mcp-architecture.md` → Replaced by `/docs/02-architecture/service-architecture.md` 31 | - `worktree-dashboard-architecture.md` → Never implemented 32 | 33 | ### outdated-guides/ 34 | Guides that reference old concepts or implementations: 35 | - `development-modes-guide.md` → Superseded by mode system v2 36 | - `orchestration-automation-vision.md` → Replaced by current orchestration architecture 37 | - `WORKTREE-USAGE.md` → Functionality now integrated into core 38 | - `websocket-claude.md` → Replaced by ChannelCoder implementation 39 | - `implementation-priorities.md` → Use task system for current priorities 40 | 41 | ## Important Note 42 | 43 | These documents may contain outdated or incorrect information. Always refer to the active documentation in: 44 | - `/docs/00-overview/` - Current overview and quick start 45 | - `/docs/01-concepts/` - Active conceptual documentation 46 | - `/docs/02-architecture/` - Current architecture documents 47 | - `/docs/specs/` - Current specifications (v2 versions) 48 | 49 | ## Why Archive Instead of Delete? 50 | 51 | 1. **Evolution History** - Shows how thinking evolved 52 | 2. **Valuable Ideas** - Some concepts might be worth revisiting 53 | 3. **Decision Context** - Explains why we moved away from certain approaches 54 | 4. **No Information Loss** - Preserves all work done -------------------------------------------------------------------------------- /docs/command-resources/README.md: -------------------------------------------------------------------------------- 1 | # Command Resources 2 | 3 | This directory contains resources used by Claude commands, organized for future tooling integration. 4 | 5 | ## Structure 6 | 7 | ``` 8 | command-resources/ 9 | ├── implement-modes/ # Mode-specific guidance for /project:05_implement 10 | ├── planning-templates/ # Templates for planning commands 11 | └── README.md # This file 12 | ``` 13 | 14 | ## Purpose 15 | 16 | These resources are referenced by Claude commands to provide: 17 | - Consistent patterns and best practices 18 | - Domain-specific guidance 19 | - Planning templates 20 | - Reusable structures 21 | 22 | ## Available Commands 23 | 24 | The following commands use these resources: 25 | - `/project:01_brainstorm-feature` - Uses planning templates 26 | - `/project:02_feature-proposal` - Uses planning templates 27 | - `/project:03_feature-to-prd` - Uses planning templates 28 | - `/project:04_feature-planning` - Uses planning templates 29 | - `/project:05_implement` - Uses mode-specific guidance from implement-modes/ 30 | - `/project:implement-next` - Automated feature implementation that uses implement modes 31 | 32 | ## Customization 33 | 34 | Projects can override these defaults by creating a parallel structure in: 35 | ``` 36 | /.scopecraft/patterns/ 37 | ├── implement-modes/ 38 | ├── planning-templates/ 39 | └── ... 40 | ``` 41 | 42 | Commands will check project-specific patterns first, then fall back to these defaults. 43 | 44 | ## Adding Resources 45 | 46 | When adding new resources: 47 | 1. Create appropriate subdirectory if needed 48 | 2. Add clear documentation in a README 49 | 3. Update relevant commands to reference new paths 50 | 4. Consider future tooling needs 51 | 52 | ## Future Integration 53 | 54 | This structure is designed to be: 55 | - Easily parseable by tools 56 | - Configurable per project 57 | - Extensible for new command types 58 | - Versionable with the codebase -------------------------------------------------------------------------------- /docs/command-resources/implement-modes/README.md: -------------------------------------------------------------------------------- 1 | # Implementation Mode Guidelines 2 | 3 | This directory contains mode-specific implementation guidance for the `/project:05_implement` command. 4 | 5 | ## Structure 6 | 7 | Each mode has its own file: 8 | - `typescript.md` - Core TypeScript development patterns 9 | - `ui.md` - React/UI component implementation 10 | - `mcp.md` - MCP server and tool development 11 | - `cli.md` - CLI command implementation 12 | - etc. 13 | 14 | ## Creating New Modes 15 | 16 | To add a new implementation mode: 17 | 18 | 1. Create a file named `{mode}.md` in this directory 19 | 2. Include: 20 | - Mode-specific best practices 21 | - Common patterns and utilities 22 | - Testing approaches 23 | - Documentation requirements 24 | - Integration considerations 25 | 26 | ## General Implementation Patterns 27 | 28 | When mode-specific guidance doesn't exist, these general patterns apply: 29 | 30 | ### 1. Code Organization 31 | - Follow existing directory structure 32 | - Keep related code together 33 | - Use clear, descriptive names 34 | 35 | ### 2. Error Handling 36 | - Handle errors gracefully 37 | - Provide meaningful error messages 38 | - Log errors appropriately 39 | 40 | ### 3. Testing 41 | - Write tests for new functionality 42 | - Follow existing test patterns 43 | - Consider edge cases 44 | 45 | ### 4. Documentation 46 | - Document complex logic 47 | - Update README files as needed 48 | - Include usage examples 49 | 50 | ### 5. Integration 51 | - Consider impact on other areas 52 | - Maintain backwards compatibility 53 | - Test integration points 54 | 55 | ## Mode Detection 56 | 57 | The `/project:05_implement` command will: 58 | 1. Look for `/docs/implement-modes/{mode}.md` 59 | 2. If found, use mode-specific guidance 60 | 3. If not found, apply general patterns and assume the role 61 | 62 | This allows the command to work with any mode, even those not yet documented. -------------------------------------------------------------------------------- /docs/command-resources/planning-templates/README.md: -------------------------------------------------------------------------------- 1 | # Planning Templates 2 | 3 | This directory contains templates used by planning-related Claude commands. 4 | 5 | ## Available Templates 6 | 7 | ### feature-planning.md 8 | Used by `/project:feature-planning` to break down features into tasks. Includes: 9 | - Problem definition 10 | - Solution overview 11 | - Task breakdown by area 12 | - Success criteria 13 | - Risk identification 14 | 15 | ## Template Usage 16 | 17 | These templates are loaded by Claude commands to provide consistent structure for planning activities. Commands will: 18 | 1. Load the appropriate template 19 | 2. Guide users to fill it out 20 | 3. Convert sections into actionable tasks 21 | 22 | ## Customization 23 | 24 | To customize templates for your project: 25 | 1. Copy templates to `/.scopecraft/patterns/templates/` 26 | 2. Modify as needed 27 | 3. Commands will use project-specific versions when available 28 | 29 | ## Creating New Templates 30 | 31 | When adding templates: 32 | - Use clear section headers 33 | - Include examples in {curly braces} 34 | - Focus on actionable outcomes 35 | - Consider how sections map to tasks -------------------------------------------------------------------------------- /docs/command-resources/planning-templates/brainstorming-guide.md: -------------------------------------------------------------------------------- 1 | # Feature Brainstorming Guide 2 | 3 | ## Overview 4 | This guide helps conduct effective feature brainstorming sessions for solo developers. Focus on understanding the problem deeply before jumping to solutions. 5 | 6 | ## Effective Brainstorming Techniques 7 | 8 | ### 1. Problem First 9 | - Start with the pain point, not the solution 10 | - Ask "why" multiple times to get to root cause 11 | - Consider who experiences this problem 12 | 13 | ### 2. Multiple Perspectives 14 | - User perspective: What's frustrating? 15 | - Developer perspective: What's inefficient? 16 | - System perspective: What's breaking? 17 | 18 | ### 3. Solution Exploration 19 | - Generate 2-3 different approaches 20 | - Consider trade-offs of each 21 | - Think about implementation complexity 22 | 23 | ## Key Questions to Ask 24 | 25 | ### Understanding the Problem 26 | 1. What specific problem are we solving? 27 | 2. How often does this occur? 28 | 3. What's the current workaround? 29 | 4. What's the impact of not solving it? 30 | 31 | ### Exploring Solutions 32 | 1. What's the simplest solution? 33 | 2. What's the ideal solution? 34 | 3. What's the pragmatic middle ground? 35 | 4. What are the technical constraints? 36 | 37 | ### Evaluating Approaches 38 | 1. How long would each take to build? 39 | 2. Which areas of code would be affected? 40 | 3. What could go wrong? 41 | 4. What dependencies exist? 42 | 43 | ## Common Pitfalls to Avoid 44 | - Jumping to complex solutions too quickly 45 | - Not considering existing code patterns 46 | - Ignoring technical debt implications 47 | - Over-engineering for future scenarios 48 | 49 | ## Output Format 50 | A good brainstorming session produces: 51 | - Clear problem statement 52 | - 2-3 solution options with trade-offs 53 | - Recommended approach with rationale 54 | - List of technical considerations 55 | - Rough implementation estimate 56 | 57 | ## Example 58 | **Problem**: "It's hard to see what tasks I worked on yesterday" 59 | 60 | **Explored Solutions**: 61 | 1. Add timestamp to task list view 62 | 2. Create activity log feature 63 | 3. Add "recently modified" filter 64 | 65 | **Recommendation**: Option 3 - simplest to implement, solves core need 66 | 67 | **Technical Considerations**: 68 | - Need to track last modified date 69 | - Add filter to task list component 70 | - ~1 day of work -------------------------------------------------------------------------------- /docs/command-resources/planning-templates/feature-planning.md: -------------------------------------------------------------------------------- 1 | # Feature Planning Template 2 | 3 | ## Problem Statement 4 | {What specific problem are we solving? Why is it important?} 5 | 6 | ## User Story 7 | As a {type of user}, I want {goal} so that {benefit}. 8 | 9 | ## Proposed Solution 10 | {High-level description of the feature. How will it work from the user's perspective?} 11 | 12 | ## Goals 13 | - {Specific measurable objective} 14 | - {Another objective} 15 | - {Keep goals SMART: Specific, Measurable, Achievable, Relevant, Time-bound} 16 | 17 | ## Non-Goals 18 | - {What this feature will NOT do} 19 | - {Explicit scope limitations} 20 | 21 | ## Technical Breakdown 22 | 23 | ### Area: UI 24 | - [ ] Task: {Specific UI component/change} 25 | - [ ] Task: {Another UI task} 26 | 27 | ### Area: Core 28 | - [ ] Task: {Core logic implementation} 29 | - [ ] Task: {Data model changes if needed} 30 | 31 | ### Area: MCP 32 | - [ ] Task: {MCP tool integration if applicable} 33 | 34 | ### Area: CLI 35 | - [ ] Task: {CLI command modifications if needed} 36 | 37 | ### Area: Docs 38 | - [ ] Task: Update documentation for new feature 39 | - [ ] Task: Add examples and usage guide 40 | 41 | ## Dependencies 42 | - {Other features or tasks that must complete first} 43 | - {External dependencies or services} 44 | 45 | ## Risks & Open Questions 46 | - [ ] {Potential technical challenge} 47 | - [ ] {Unresolved design question} 48 | - [ ] {Performance or scalability concern} 49 | 50 | ## Success Criteria 51 | - [ ] {How we'll know the feature is complete} 52 | - [ ] {Acceptance criteria from user perspective} 53 | - [ ] {Performance or quality metrics if applicable} 54 | 55 | ## Implementation Notes 56 | {Any additional context, design decisions, or technical considerations} 57 | 58 | ## Human Review Required 59 | 60 | Planning decisions to verify: 61 | - [ ] Complexity assessment (simple vs feature-worthy) 62 | - [ ] Area designation via tags vs folders 63 | - [ ] Task granularity for AI session scope 64 | - [ ] Sequential dependencies identified correctly 65 | - [ ] Original PRD properly linked/referenced 66 | - [ ] Feature folder organization appropriate 67 | - [ ] Correct phase assignment 68 | - [ ] Task breakdown completeness 69 | 70 | Technical assumptions: 71 | - [ ] Architecture decisions implicit in task breakdown 72 | - [ ] Integration approach assumptions 73 | - [ ] Performance/scaling considerations 74 | - [ ] Security implementation needs -------------------------------------------------------------------------------- /docs/command-resources/planning-templates/feature-prd.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | # Feature Specification: {Title} [DRAFT] 4 | 5 | ## Overview 6 | {1-2 sentence summary of the feature} 7 | 8 | ## Requirements 9 | ### Functional Requirements 10 | 1. {Specific requirement} 11 | 2. {Another requirement} 12 | 13 | ### Technical Requirements 14 | - {Performance needs} 15 | - {Security considerations} 16 | - {Integration points} 17 | 18 | ## UI/UX Design 19 | ### User Flow 20 | 1. {Step 1} 21 | 2. {Step 2} 22 | 23 | ### Key Screens 24 | - {Screen 1}: {Purpose} 25 | - {Screen 2}: {Purpose} 26 | 27 | ## Technical Design 28 | ### Components Affected 29 | - {Component}: {Changes needed} 30 | 31 | ### Data Model Changes 32 | {New fields, tables, or structures} 33 | 34 | *Note: TypeScript interfaces shown are illustrative examples, not prescriptive* 35 | 36 | ### API Changes 37 | {New endpoints or modifications} 38 | 39 | ## Implementation Notes 40 | - {Important decisions} 41 | - {Gotchas to watch for} 42 | - {Suggested approach} 43 | 44 | ## Testing Approach 45 | - {What needs testing} 46 | - {Critical test cases} 47 | 48 | ## Task Breakdown Preview 49 | - UI: {Main UI tasks} 50 | - Core: {Core logic tasks} 51 | - API: {API tasks} 52 | - Tests: {Testing tasks} 53 | - Docs: {Documentation tasks} 54 | 55 | ## Human Review Required 56 | 57 | *Note: This section helps track assumptions and decisions made during PRD creation* 58 | 59 | ### Technical decisions needing verification: 60 | - [ ] Component architecture assumptions 61 | - [ ] Data model design choices 62 | - [ ] API interface decisions 63 | - [ ] Performance optimization approaches 64 | 65 | ### Design decisions to confirm: 66 | - [ ] UI/UX flow assumptions 67 | - [ ] User interaction patterns 68 | - [ ] Error handling strategies 69 | - [ ] Edge case coverage 70 | 71 | ### Implementation concerns: 72 | - [ ] Task breakdown completeness 73 | - [ ] Dependency identification 74 | - [ ] Testing strategy adequacy -------------------------------------------------------------------------------- /docs/command-resources/planning-templates/feature-proposal.md: -------------------------------------------------------------------------------- 1 | # Feature Proposal: {Title} 2 | 3 | ## Problem Statement 4 | {What specific problem are we solving? Why does it matter?} 5 | 6 | ## Proposed Solution 7 | {Clear description of what we'll build} 8 | 9 | ## Key Benefits 10 | - {Primary benefit} 11 | - {Secondary benefit} 12 | 13 | ## Scope 14 | ### Included 15 | - {What this feature WILL do} 16 | 17 | ### Not Included 18 | - {What this feature WON'T do} 19 | 20 | ## Technical Approach 21 | {High-level technical strategy} 22 | 23 | ## Implementation Estimate 24 | {Rough time estimate: days/weeks} 25 | 26 | ## Dependencies 27 | - {What must exist first?} 28 | - {External dependencies} 29 | 30 | ## Risks 31 | - {Technical challenges} 32 | - {Potential blockers} 33 | 34 | ## Open Questions 35 | - {Unresolved decisions} -------------------------------------------------------------------------------- /docs/fish-shell-cd-integration.md: -------------------------------------------------------------------------------- 1 | # Fish Shell CD Integration for Task Worktrees 2 | 3 | ## Overview 4 | 5 | The `tw-start` script has been modified to output the worktree directory path to stdout, allowing fish shell (or any shell) to capture this path and change to that directory. 6 | 7 | ## How It Works 8 | 9 | 1. The script creates the worktree as before 10 | 2. Installs dependencies 11 | 3. Instead of launching Claude, it outputs the worktree path to stdout 12 | 4. The fish function captures this output and uses `cd` to change to that directory 13 | 14 | ## Fish Function 15 | 16 | ```fish 17 | function tw-start 18 | # Run the bun script and capture the output 19 | set worktree_dir (bun run tw-start $argv | tail -n 1) 20 | 21 | # Check if the command was successful 22 | if test $status -eq 0 23 | # Change to the worktree directory 24 | cd $worktree_dir 25 | echo "Changed to worktree directory: $worktree_dir" 26 | else 27 | echo "Failed to create worktree" 28 | return 1 29 | end 30 | end 31 | ``` 32 | 33 | ## Usage 34 | 35 | ```fish 36 | # In your fish shell 37 | tw-start TASK-123456 38 | 39 | # This will: 40 | # 1. Create the worktree 41 | # 2. Install dependencies 42 | # 3. Change your current directory to the new worktree 43 | ``` 44 | 45 | ## Installation 46 | 47 | 1. Copy the fish function to your fish config: 48 | ```bash 49 | cp scripts/fish-functions/tw-start.fish ~/.config/fish/functions/ 50 | ``` 51 | 52 | 2. Or run the setup script: 53 | ```bash 54 | bun scripts/setup-fish-integration.sh 55 | ``` 56 | 57 | The function will be available in all new fish shells. To use it immediately, source it: 58 | ```fish 59 | source ~/.config/fish/functions/tw-start.fish 60 | ``` -------------------------------------------------------------------------------- /orchestrate: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | # Orchestration CLI wrapper (interactive mode) 4 | # This delegates to the new work command with orchestration mode 5 | 6 | # Check if we have at least one argument (parentId) 7 | if [ $# -eq 0 ]; then 8 | echo "Usage: ./orchestrate [additional instructions...]" 9 | echo "Example: ./orchestrate impl-cli-env-mgmt-06A" 10 | echo "Example: ./orchestrate impl-cli-env-mgmt-06A \"Focus on Phase 4 tasks\"" 11 | exit 1 12 | fi 13 | 14 | # Pass parentId and any additional arguments to work command with orchestration mode 15 | exec bun run dev:cli work "$@" --mode orchestration -------------------------------------------------------------------------------- /orchestrate-auto: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | # Autonomous orchestration CLI wrapper 4 | # This delegates to the new dispatch command with orchestration mode 5 | 6 | # Check if we have at least one argument (parentId) 7 | if [ $# -eq 0 ]; then 8 | echo "Usage: ./orchestrate-auto " 9 | echo "Example: ./orchestrate-auto impl-cli-env-mgmt-06A" 10 | exit 1 11 | fi 12 | 13 | # Use dispatch command with orchestration mode 14 | # Pass auto=true via --data to indicate autonomous orchestration 15 | exec bun run dev:cli dispatch "$@" --mode orchestration --data '{"auto":"true"}' --exec detached -------------------------------------------------------------------------------- /plan: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | # Planning CLI wrapper 4 | # This delegates to the new plan command 5 | 6 | # Check if we have at least one argument 7 | if [ $# -eq 0 ]; then 8 | echo "Usage: ./plan " 9 | echo "Example: ./plan \"Add dark mode toggle\"" 10 | echo "Example: ./plan \"Build OAuth integration with GitHub\"" 11 | exit 1 12 | fi 13 | 14 | # Pass all arguments to the plan command 15 | exec bun run dev:cli plan "$@" -------------------------------------------------------------------------------- /scripts/README.md: -------------------------------------------------------------------------------- 1 | # Scopecraft Scripts 2 | 3 | This directory contains utility scripts for Scopecraft operations. 4 | 5 | ## migrate-to-centralized-storage.ts 6 | 7 | Migrates tasks from local `.tasks/` directory to the new centralized storage location at `~/.scopecraft/projects/{encoded}/tasks/`. 8 | 9 | ### Usage 10 | 11 | ```bash 12 | # Preview what will be migrated (recommended first step) 13 | bun scripts/migrate-to-centralized-storage.ts --dry-run 14 | 15 | # Perform the actual migration 16 | bun scripts/migrate-to-centralized-storage.ts 17 | 18 | # Force overwrite any conflicts without prompting 19 | bun scripts/migrate-to-centralized-storage.ts --force 20 | ``` 21 | 22 | ### Features 23 | 24 | - Migrates tasks from `backlog/`, `current/`, and `archive/` workflows 25 | - Preserves directory structure including parent task folders 26 | - **Automatic MD5 comparison** - Identical files are skipped without prompting 27 | - Detects conflicts and shows task metadata (title, status, type) for resolution 28 | - Interactive conflict resolution with options to: 29 | - Keep local version (overwrite central) 30 | - Keep central version (skip local) 31 | - Skip the file entirely 32 | - Works correctly from worktrees (detects main repository) 33 | - Provides migration summary with counts including identical files 34 | 35 | ### What it migrates 36 | 37 | - All `.task.md` files 38 | - Parent task `_overview.md` files 39 | - Preserves the complete directory structure 40 | 41 | ### What it doesn't migrate (yet) 42 | 43 | - Templates (`.tasks/.templates/`) 44 | - Modes (`.tasks/.modes/`) 45 | - Session data (`.sessions/`) 46 | 47 | These require special handling due to potential sharing models (user-level vs project-level). 48 | 49 | ### After migration 50 | 51 | Once migration is complete and verified, you can safely remove the local `.tasks/` directory: 52 | 53 | ```bash 54 | rm -rf .tasks/ 55 | ``` -------------------------------------------------------------------------------- /scripts/fish-functions/README.md: -------------------------------------------------------------------------------- 1 | # Fish Shell Functions for Task Worktree Management 2 | 3 | This directory contains fish shell functions that integrate with the roo-task-cli's worktree management system. 4 | 5 | ## Installation 6 | 7 | 1. Copy the fish functions to your fish configuration directory: 8 | ```fish 9 | cp scripts/fish-functions/*.fish ~/.config/fish/functions/ 10 | ``` 11 | 12 | 2. Or source them directly in your fish configuration: 13 | ```fish 14 | source /path/to/roo-task-cli/scripts/fish-functions/tw-start.fish 15 | source /path/to/roo-task-cli/scripts/fish-functions/tw-feat-start.fish 16 | ``` 17 | 18 | ## Usage 19 | 20 | ### tw-start 21 | 22 | Starts a task worktree and automatically changes to its directory: 23 | 24 | ```fish 25 | # Start a specific task 26 | tw-start TASK-20241231T123456 27 | 28 | # The function will: 29 | # 1. Create a new worktree for the task 30 | # 2. Install dependencies 31 | # 3. Change your terminal to the worktree directory 32 | ``` 33 | 34 | ### tw-feat-start 35 | 36 | Starts a feature worktree and automatically changes to its directory: 37 | 38 | ```fish 39 | # Start a specific feature 40 | tw-feat-start FEATURE_auth 41 | 42 | # The function will: 43 | # 1. Create a new worktree for the entire feature 44 | # 2. Install dependencies 45 | # 3. Change your terminal to the worktree directory 46 | ``` 47 | 48 | This is useful when you want to work on an entire feature rather than individual tasks. The worktree will be named after the feature, and you can use `/project:implement-next` to automatically find and implement the next task in the feature. 49 | 50 | ## How it Works 51 | 52 | The modified worktree scripts now: 53 | 1. Create the worktree as before 54 | 2. Install dependencies 55 | 3. Output the worktree directory path to stdout (without trailing messages) 56 | 57 | The fish functions: 58 | 1. Run the bun script and capture the last line of output (the directory path) 59 | 2. Change to that directory if the command was successful 60 | 3. Provide feedback about the directory change 61 | 62 | This approach allows the script to change the parent shell's directory, which is not possible from within a subprocess. -------------------------------------------------------------------------------- /scripts/fish-functions/tw-feat-start.fish: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env fish 2 | # Fish shell function to start a feature worktree and change to its directory 3 | 4 | function tw-feat-start 5 | # Run the bun script and capture the output 6 | set worktree_dir (bun run tw-feat-start $argv | tail -n 1) 7 | 8 | # Check if the command was successful 9 | if test $status -eq 0 10 | # Change to the worktree directory 11 | cd $worktree_dir 12 | echo "Changed to feature worktree directory: $worktree_dir" 13 | else 14 | echo "Failed to create feature worktree" 15 | return 1 16 | end 17 | end -------------------------------------------------------------------------------- /scripts/fish-functions/tw-start.fish: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env fish 2 | # Fish shell function to start a task worktree and change to its directory 3 | 4 | function tw-start 5 | # Run the bun script and capture the output 6 | set worktree_dir (bun run tw-start $argv | tail -n 1) 7 | 8 | # Check if the command was successful 9 | if test $status -eq 0 10 | # Change to the worktree directory 11 | cd $worktree_dir 12 | echo "Changed to worktree directory: $worktree_dir" 13 | else 14 | echo "Failed to create worktree" 15 | return 1 16 | end 17 | end -------------------------------------------------------------------------------- /scripts/fix-e2e-tests.ts: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env bun 2 | import { readFileSync, writeFileSync } from 'fs'; 3 | import { glob } from 'glob'; 4 | 5 | // Find all e2e test files 6 | const testFiles = await glob('test/e2e/*.test.ts'); 7 | 8 | for (const file of testFiles) { 9 | let content = readFileSync(file, 'utf-8'); 10 | 11 | // Fix 1: Add main branch creation after git init 12 | if (content.includes('await git.init();') && !content.includes('checkoutLocalBranch')) { 13 | content = content.replace( 14 | /await git\.init\(\);\n(\s*)await git\.addConfig/g, 15 | `await git.init();\n$1await git.checkoutLocalBranch('main');\n$1await git.addConfig` 16 | ); 17 | } 18 | 19 | // Fix 2: Ensure worktree cleanup is wrapped in try-catch 20 | content = content.replace( 21 | /const worktrees = await git\.raw\(\['worktree', 'list', '--porcelain'\]\);/g, 22 | `try {\n const worktrees = await git.raw(['worktree', 'list', '--porcelain']);` 23 | ); 24 | 25 | // Fix 3: Close the try block for worktree cleanup 26 | if (content.includes('try {\n const worktrees')) { 27 | content = content.replace( 28 | /await git\.raw\(\['worktree', 'prune'\]\);\n(\s*)\}/g, 29 | `await git.raw(['worktree', 'prune']);\n$1} catch {\n$1 // Ignore worktree errors\n$1}` 30 | ); 31 | } 32 | 33 | writeFileSync(file, content); 34 | console.log(`Fixed: ${file}`); 35 | } 36 | 37 | console.log('Done fixing e2e tests'); -------------------------------------------------------------------------------- /scripts/install-local.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | # Install the local package globally 3 | # This script can be run from the ~/MCP/scopecraft directory 4 | 5 | # Find the latest version of the package 6 | LATEST_PACKAGE=$(ls -t ~/MCP/scopecraft/scopecraft-cmd-*.tgz | head -1) 7 | 8 | if [ -z "$LATEST_PACKAGE" ]; then 9 | echo "Error: No package file found in ~/MCP/scopecraft/" 10 | echo "Run 'npm run publish:local' first to create the package" 11 | exit 1 12 | fi 13 | 14 | echo "Installing package: $LATEST_PACKAGE" 15 | 16 | # Uninstall any existing installations first 17 | npm uninstall -g @scopecraft/cmd 18 | 19 | # Install the package globally 20 | npm install -g "$LATEST_PACKAGE" 21 | 22 | # Check installation path 23 | NPM_GLOBAL_PATH=$(npm root -g) 24 | INSTALL_PATH=$(find "$NPM_GLOBAL_PATH" -name "scopecraft-cmd" | head -1) 25 | echo "Package installed at: $INSTALL_PATH" 26 | 27 | # Verify installation 28 | echo "Verifying installation:" 29 | sc --version 30 | sc-mcp --version 31 | sc-stdio --version 32 | 33 | # Print PATH information for debugging 34 | echo "PATH entries:" 35 | echo $PATH | tr ':' '\n' | grep -i npm 36 | 37 | echo "Successfully installed @scopecraft/cmd locally" -------------------------------------------------------------------------------- /scripts/prompts/release-analysis.md: -------------------------------------------------------------------------------- 1 | --- 2 | allowedTools: 3 | - "Bash(git log:*)" 4 | - "Bash(git diff:*)" 5 | - "Bash(git show:*)" 6 | - "Bash(cd:*)" 7 | - "Read" 8 | - "Write" 9 | --- 10 | 11 | # Complete Release Analysis Task 12 | 13 | **YOUR TASK**: Analyze git changes since v$LAST_TAG and create THREE FILES. 14 | 15 | ## Context 16 | - Current Version: $CURRENT_VERSION 17 | - Last Tag: $LAST_TAG 18 | - Release Date: $RELEASE_DATE 19 | - Target Version: $REQUESTED_VERSION 20 | 21 | ## Step 1: Analyze Changes 22 | Run these commands to understand the changes: 23 | ```bash 24 | git log $LAST_TAG..HEAD --oneline 25 | git diff $LAST_TAG..HEAD --stat 26 | ``` 27 | 28 | ## Step 2: Create Files 29 | 30 | You MUST create these three files: 31 | 32 | ### 1. Create `.release/version.json` 33 | ```json 34 | { 35 | "current_version": "$CURRENT_VERSION", 36 | "new_version": "X.Y.Z", 37 | "bump_type": "major|minor|patch", 38 | "confidence": "high|medium|low", 39 | "reasoning": "Brief explanation", 40 | "breaking_changes": false, 41 | "notable_features": ["feature1", "feature2"] 42 | } 43 | ``` 44 | 45 | ### 2. Create `.release/changelog.md` 46 | Standard changelog format focusing on USER-FACING changes only: 47 | ```markdown 48 | ## [X.Y.Z] - $RELEASE_DATE 49 | 50 | ### Added 51 | - **Feature Name**: User benefit description 52 | 53 | ### Changed 54 | - **Feature Name**: What changed for users 55 | 56 | ### Fixed 57 | - **Issue Area**: What was broken and now works 58 | ``` 59 | 60 | ### 3. Create `.release/metadata.json` 61 | ```json 62 | { 63 | "success": true, 64 | "version": "X.Y.Z", 65 | "release_date": "$RELEASE_DATE", 66 | "summary": "One-line release summary", 67 | "breaking_changes": false, 68 | "highlights": ["Most important change", "Second most important"], 69 | "categories_used": ["Added", "Fixed"], 70 | "total_changes": 5 71 | } 72 | ``` 73 | 74 | ## CRITICAL INSTRUCTIONS 75 | 76 | 1. **ANALYZE THOROUGHLY** - Examine commit messages and code changes for breaking changes 77 | 2. **CREATE ALL THREE FILES** - Use the Write tool to create each file 78 | 3. **FOCUS ON USER IMPACT** - Changes to these paths ARE user-facing: 79 | - `src/` - Core CLI and MCP server functionality 80 | - `tasks-ui/` - Web UI functionality 81 | - `dist/` - Built artifacts 82 | - Changes to scripts/, docs/, tests/ are NOT user-facing unless they fix bugs 83 | 4. **USE SEMANTIC VERSIONING** - Major (breaking), Minor (features), Patch (fixes) 84 | 85 | **BEGIN ANALYSIS** - Create the three files based on your git analysis. -------------------------------------------------------------------------------- /scripts/prompts/systems/changelog-writer.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: "Technical Communication Specialist for software release notes" 3 | --- 4 | 5 | You are a Technical Communication Specialist specializing in creating user-facing changelogs for CLI tools and developer services. 6 | 7 | ## Writing Mission 8 | Transform technical code changes into clear, user-focused release notes. Focus ONLY on changes that directly impact end users - CLI commands, MCP endpoints, task-UI features, and user-visible bug fixes. Ignore all internal development changes. 9 | 10 | ## Writing Style 11 | - **User-focused**: Describe benefits and impact, not implementation details 12 | - **Scannable**: Use clear bullet points and consistent formatting 13 | - **Value-driven**: Lead with what users can now do or problems solved 14 | - **Concise**: Get to the point quickly while being complete 15 | - **Consistent**: Follow established patterns and tone 16 | 17 | ## Content Guidelines 18 | 19 | ### Include (User-Facing Only) 20 | - CLI commands and options that users run 21 | - MCP endpoints that Claude Code can access 22 | - Task-UI features that affect workflows 23 | - User-visible bug fixes and improvements 24 | - Performance changes users will notice 25 | - Breaking changes requiring user action 26 | - Security fixes affecting user safety 27 | 28 | ### Exclude (Internal Changes) 29 | - Build systems, CI/CD, development tooling 30 | - Code refactoring and architecture changes 31 | - Test improvements and quality tools 32 | - Documentation and internal processes 33 | - Release scripts and automation 34 | - Dependency updates without user impact 35 | 36 | ## Formatting Standards 37 | - Use "Added/Changed/Fixed/Security" categorization 38 | - Start each item with **Feature/Area Name** in bold 39 | - Follow with clear description of user impact 40 | - Use consistent voice and tense 41 | - Include relevant context without technical jargon 42 | 43 | ## Output Requirements 44 | - Always return structured JSON response 45 | - Group changes by category 46 | - Prioritize most important changes first 47 | - Include user-friendly descriptions 48 | - Flag any breaking changes clearly -------------------------------------------------------------------------------- /scripts/prompts/systems/release-manager.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: "Release Manager AI specialized in software release processes" 3 | --- 4 | 5 | You are a Release Manager AI specialized in software release processes. 6 | 7 | ## Core Responsibilities 8 | - Analyze code changes for version impact 9 | - Generate user-focused release documentation 10 | - Ensure release quality and consistency 11 | - Follow semantic versioning principles 12 | 13 | ## Behavioral Constraints 14 | - Always output structured JSON responses when requested 15 | - Never include sensitive implementation details 16 | - Focus on user value, not technical internals 17 | - Be concise but comprehensive 18 | - Prioritize clarity over completeness 19 | 20 | ## Security Requirements 21 | - Never expose internal file paths in user-facing content 22 | - Exclude dependency bumps unless they impact users 23 | - Avoid mentioning debugging or development tools 24 | - Filter out maintenance commits and noise 25 | 26 | ## Output Standards 27 | - Use active voice and present tense 28 | - Group changes logically (Added/Changed/Fixed/Security) 29 | - Include impact/value statements 30 | - Use consistent formatting 31 | - Always include success/failure indicators in JSON responses 32 | - Write for end users, not developers -------------------------------------------------------------------------------- /scripts/prompts/systems/version-analyzer.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: "Semantic Versioning Analyst for determining version bumps" 3 | --- 4 | 5 | You are a Semantic Versioning Analyst specializing in determining appropriate version bumps based on code changes. 6 | 7 | ## Core Rules 8 | - **Breaking changes** → MAJOR bump (1.0.0 → 2.0.0) 9 | - **New features** → MINOR bump (1.0.0 → 1.1.0) 10 | - **Bug fixes** → PATCH bump (1.0.0 → 1.0.1) 11 | 12 | ## Analysis Factors 13 | - API changes and backward compatibility 14 | - New user-facing functionality 15 | - Behavior modifications that affect users 16 | - Bug fixes and security improvements 17 | - Configuration or interface changes 18 | 19 | ## Analysis Process 20 | 1. Review commit messages for change indicators 21 | 2. Analyze code diffs for breaking changes 22 | 3. Identify new features vs enhancements 23 | 4. Assess impact on existing users 24 | 5. Determine confidence level in recommendation 25 | 26 | ## Output Requirements 27 | - Always provide JSON with version recommendation 28 | - Include confidence level (high/medium/low) 29 | - Explain reasoning for the recommendation 30 | - Flag any uncertainties or edge cases 31 | - Suggest next version number explicitly -------------------------------------------------------------------------------- /scripts/run-e2e-mcp-tests.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | # Script to run MCP end-to-end tests and save results to a timestamped file 3 | 4 | # Change to the project directory 5 | cd "$(dirname "$0")/.." 6 | 7 | # Create results directory if it doesn't exist 8 | RESULTS_DIR="test/mcp/results" 9 | mkdir -p "$RESULTS_DIR" 10 | 11 | # Generate timestamp for unique filename 12 | TIMESTAMP=$(date +"%Y%m%d_%H%M%S") 13 | RESULTS_FILE="$RESULTS_DIR/e2e_mcp_test_$TIMESTAMP.json" 14 | 15 | echo "Starting MCP end-to-end tests..." 16 | echo "Results will be saved to: $RESULTS_FILE" 17 | 18 | # Run the Claude CLI command and save output to the results file 19 | claude -p "/project:e2e-mcp-test" --output-format stream-json \ 20 | --allowedTools \ 21 | "mcp__scopecraft-command-mcp__task_list" \ 22 | "mcp__scopecraft-command-mcp__task_get" \ 23 | "mcp__scopecraft-command-mcp__task_create" \ 24 | "mcp__scopecraft-command-mcp__task_update" \ 25 | "mcp__scopecraft-command-mcp__task_delete" \ 26 | "mcp__scopecraft-command-mcp__task_next" \ 27 | "mcp__scopecraft-command-mcp__phase_list" \ 28 | "mcp__scopecraft-command-mcp__phase_create" \ 29 | "mcp__scopecraft-command-mcp__workflow_current" \ 30 | "mcp__scopecraft-command-mcp__workflow_mark_complete_next" \ 31 | "Batch" \ 32 | "Read" \ 33 | "LS" > "$RESULTS_FILE" 34 | 35 | echo "Tests completed successfully!" 36 | echo "Results saved to: $RESULTS_FILE" 37 | 38 | # Optionally add a command to view or process the results file 39 | # For example, to extract just the final summary: 40 | # echo "Test Summary:" 41 | # cat "$RESULTS_FILE" | grep -A 20 "Summary Report" | tail -20 -------------------------------------------------------------------------------- /scripts/setup-fish-integration.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | # Setup script for fish shell integration with roo-task-cli 3 | 4 | echo "Setting up fish shell integration for roo-task-cli..." 5 | 6 | # Check if fish is installed 7 | if ! command -v fish &> /dev/null; then 8 | echo "Error: fish shell is not installed" 9 | exit 1 10 | fi 11 | 12 | # Create fish functions directory if it doesn't exist 13 | FISH_FUNCTIONS_DIR="$HOME/.config/fish/functions" 14 | mkdir -p "$FISH_FUNCTIONS_DIR" 15 | 16 | # Copy the tw-start function 17 | cp scripts/fish-functions/tw-start.fish "$FISH_FUNCTIONS_DIR/" 18 | 19 | echo "Fish function 'tw-start' has been installed!" 20 | echo "" 21 | echo "Usage:" 22 | echo " tw-start TASK-ID # Start a task and cd to its worktree" 23 | echo "" 24 | echo "The function is now available in all new fish shells." 25 | echo "To use it in the current shell, run: source ~/.config/fish/functions/tw-start.fish" -------------------------------------------------------------------------------- /scripts/test-fish-integration.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | # Test the fish function integration 3 | 4 | echo "Testing tw-start output..." 5 | 6 | # Run the script with a fake task ID to see the output 7 | # We'll redirect stderr to /dev/null to only see the path output 8 | OUTPUT=$(bun run tw-start TASK-TEST-001 2>/dev/null | tail -n 1) 9 | 10 | echo "Output from tw-start: $OUTPUT" 11 | 12 | # Check if the output looks like a path 13 | if [[ "$OUTPUT" == *"/roo-task-cli.worktrees/"* ]]; then 14 | echo "✓ Success: Script outputs a worktree directory path" 15 | else 16 | echo "✗ Error: Script did not output expected path format" 17 | echo "Got: $OUTPUT" 18 | fi -------------------------------------------------------------------------------- /scripts/update-cli-version.ts: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env bun 2 | /** 3 | * Script to update version numbers in CLI files and package.json 4 | * Usage: bun run update-version [new-version] 5 | * If no version is provided, uses the current version in package.json 6 | */ 7 | 8 | import fs from 'fs'; 9 | import path from 'path'; 10 | import { fileURLToPath } from 'url'; 11 | 12 | // Get current directory 13 | const __filename = fileURLToPath(import.meta.url); 14 | const __dirname = path.dirname(__filename); 15 | const rootDir = path.join(__dirname, '..'); 16 | 17 | // Check for version argument 18 | const newVersion = process.argv[2]; 19 | 20 | // Read package.json 21 | const packageJsonPath = path.join(rootDir, 'package.json'); 22 | const packageJson = JSON.parse(fs.readFileSync(packageJsonPath, 'utf-8')); 23 | let version = packageJson.version; 24 | 25 | // Update package.json if new version provided 26 | if (newVersion) { 27 | packageJson.version = newVersion; 28 | fs.writeFileSync(packageJsonPath, JSON.stringify(packageJson, null, 2) + '\n'); 29 | console.log(`Updated package.json version to ${newVersion}`); 30 | version = newVersion; 31 | } else if (!version) { 32 | console.error('Error: No version found in package.json'); 33 | process.exit(1); 34 | } 35 | 36 | console.log(`Updating CLI files to version ${version}`); 37 | 38 | // Files to update 39 | const filesToUpdate = [ 40 | path.join(rootDir, 'src', 'cli', 'cli.ts'), 41 | path.join(rootDir, 'src', 'mcp', 'cli.ts') 42 | ]; 43 | 44 | // Find and replace version in each file 45 | filesToUpdate.forEach(filePath => { 46 | let content = fs.readFileSync(filePath, 'utf-8'); 47 | 48 | // Match the version assignment pattern 49 | const versionRegex = /(let|const)\s+version\s*=\s*['"]([^'"]+)['"]\s*;?\s*\/\/\s*Default/; 50 | 51 | if (versionRegex.test(content)) { 52 | // Replace the version 53 | content = content.replace(versionRegex, `$1 version = '${version}'; // Default`); 54 | fs.writeFileSync(filePath, content); 55 | console.log(`Updated version in ${path.relative(rootDir, filePath)}`); 56 | } else { 57 | console.warn(`Could not find version pattern in ${path.relative(rootDir, filePath)}`); 58 | } 59 | }); 60 | 61 | console.log('Version update complete'); -------------------------------------------------------------------------------- /src/cli/validation-helpers.ts: -------------------------------------------------------------------------------- 1 | /** 2 | * Validation helpers for CLI commands 3 | * Uses the metadata schema to provide helpful error messages 4 | */ 5 | 6 | import { 7 | getAllowedValues, 8 | isValidPhase, 9 | isValidPriority, 10 | isValidStatus, 11 | isValidType, 12 | isValidWorkflowState, 13 | } from '../core/metadata/schema-service.js'; 14 | 15 | /** 16 | * Validate and normalize task status 17 | */ 18 | export function validateStatus(status?: string): string | undefined { 19 | if (!status) return undefined; 20 | 21 | if (!isValidStatus(status)) { 22 | const allowed = getAllowedValues('status'); 23 | throw new Error(`Invalid status "${status}". Allowed values: ${allowed.join(', ')}`); 24 | } 25 | 26 | return status; 27 | } 28 | 29 | /** 30 | * Validate and normalize task type 31 | */ 32 | export function validateType(type: string): string { 33 | if (!isValidType(type)) { 34 | const allowed = getAllowedValues('type'); 35 | throw new Error(`Invalid type "${type}". Allowed values: ${allowed.join(', ')}`); 36 | } 37 | 38 | return type; 39 | } 40 | 41 | /** 42 | * Validate and normalize task priority 43 | */ 44 | export function validatePriority(priority?: string): string | undefined { 45 | if (!priority) return undefined; 46 | 47 | if (!isValidPriority(priority)) { 48 | const allowed = getAllowedValues('priority'); 49 | throw new Error(`Invalid priority "${priority}". Allowed values: ${allowed.join(', ')}`); 50 | } 51 | 52 | return priority; 53 | } 54 | 55 | /** 56 | * Validate and normalize workflow state 57 | */ 58 | export function validateWorkflowState(state?: string): string | undefined { 59 | if (!state) return undefined; 60 | 61 | if (!isValidWorkflowState(state)) { 62 | const allowed = getAllowedValues('workflowState'); 63 | throw new Error(`Invalid workflow state "${state}". Allowed values: ${allowed.join(', ')}`); 64 | } 65 | 66 | return state; 67 | } 68 | 69 | /** 70 | * Validate and normalize task phase 71 | */ 72 | export function validatePhase(phase?: string): string | undefined { 73 | if (!phase) return undefined; 74 | 75 | if (!isValidPhase(phase)) { 76 | const allowed = getAllowedValues('phase'); 77 | throw new Error(`Invalid phase "${phase}". Allowed values: ${allowed.join(', ')}`); 78 | } 79 | 80 | return phase; 81 | } 82 | -------------------------------------------------------------------------------- /src/core/config/index.ts: -------------------------------------------------------------------------------- 1 | /** 2 | * Configuration module exports 3 | */ 4 | 5 | export { ConfigurationManager } from './configuration-manager.js'; 6 | export * from './types.js'; 7 | -------------------------------------------------------------------------------- /src/core/environment/index.ts: -------------------------------------------------------------------------------- 1 | /** 2 | * Environment Management Module 3 | * 4 | * Provides core utilities for environment resolution and worktree management. 5 | * All components follow the principle of centralized configuration. 6 | */ 7 | 8 | // Export all types 9 | export * from './types.js'; 10 | 11 | // Export path resolver 12 | export { WorktreePathResolver } from './worktree-path-resolver.js'; 13 | 14 | // Export configuration services 15 | export { 16 | BranchNamingService, 17 | DockerConfigService, 18 | ModeDefaultsService, 19 | OutputFormatService, 20 | } from './configuration-services.js'; 21 | 22 | // Export worktree manager 23 | export { WorktreeManager } from './worktree-manager.js'; 24 | 25 | // Export environment resolver (class-based for backward compatibility) 26 | export { EnvironmentResolver } from './resolver.js'; 27 | 28 | // Export pure worktree functions 29 | export * from './worktree-functions.js'; 30 | 31 | // Export pure environment resolver functions 32 | export { 33 | resolveEnvironmentId, 34 | getWorktreePath, 35 | getBranchNameForTask, 36 | ensureEnvironment, 37 | getEnvironmentInfo, 38 | getTaskEnvironmentInfo, 39 | ensureTaskEnvironment, 40 | } from './resolver-functions.js'; 41 | 42 | // Import classes for factory functions 43 | import { EnvironmentResolver as EnvironmentResolverClass } from './resolver.js'; 44 | import { WorktreeManager as WorktreeManagerClass } from './worktree-manager.js'; 45 | import { WorktreePathResolver as WorktreePathResolverClass } from './worktree-path-resolver.js'; 46 | 47 | // Export convenience factory functions 48 | export function createEnvironmentResolver(): EnvironmentResolverClass { 49 | return new EnvironmentResolverClass(); 50 | } 51 | 52 | export function createWorktreeManager(): WorktreeManagerClass { 53 | return new WorktreeManagerClass(); 54 | } 55 | 56 | export function createPathResolver(): WorktreePathResolverClass { 57 | return new WorktreePathResolverClass(); 58 | } 59 | -------------------------------------------------------------------------------- /src/core/environment/worktree-manager.ts: -------------------------------------------------------------------------------- 1 | /** 2 | * Worktree Manager 3 | * 4 | * Class-based wrapper around pure worktree functions for backward compatibility. 5 | * Uses ChannelCoder utilities to avoid duplication. 6 | */ 7 | 8 | import type { ConfigurationManager } from '../config/configuration-manager.js'; 9 | import type { BranchNamingService } from './configuration-services.js'; 10 | import { 11 | EnvironmentError, 12 | EnvironmentErrorCodes, 13 | type WorktreeManager as IWorktreeManager, 14 | type WorktreeInfo, 15 | type WorktreeOptions, 16 | } from './types.js'; 17 | import { 18 | type WorktreeContext, 19 | createWorktree, 20 | createWorktreeContext, 21 | getWorktreePath, 22 | listWorktrees, 23 | removeWorktree, 24 | worktreeExists, 25 | } from './worktree-functions.js'; 26 | import type { WorktreePathResolver } from './worktree-path-resolver.js'; 27 | 28 | export class WorktreeManager implements IWorktreeManager { 29 | private context: WorktreeContext; 30 | 31 | constructor( 32 | config?: ConfigurationManager, 33 | pathResolver?: WorktreePathResolver, 34 | branchNaming?: BranchNamingService 35 | ) { 36 | this.context = createWorktreeContext(config, pathResolver, branchNaming); 37 | } 38 | 39 | /** 40 | * Creates a new worktree for the given task 41 | */ 42 | async create(taskId: string, options?: WorktreeOptions): Promise { 43 | return createWorktree(taskId, this.context, options); 44 | } 45 | 46 | /** 47 | * Removes a worktree safely 48 | */ 49 | async remove(taskId: string): Promise { 50 | return removeWorktree(taskId, this.context); 51 | } 52 | 53 | /** 54 | * Lists all active worktrees 55 | */ 56 | async list(): Promise { 57 | return listWorktrees(this.context); 58 | } 59 | 60 | /** 61 | * Checks if a worktree exists 62 | */ 63 | async exists(taskId: string): Promise { 64 | return worktreeExists(taskId, this.context); 65 | } 66 | 67 | /** 68 | * Gets the path for a worktree (doesn't check existence) 69 | */ 70 | getPath(_taskId: string): string { 71 | // This is synchronous, but we need to handle the async path resolver 72 | // For now, we'll throw an error - the async version should be used 73 | throw new EnvironmentError( 74 | 'Use getWorktreePath() for async path resolution', 75 | EnvironmentErrorCodes.CONFIGURATION_ERROR 76 | ); 77 | } 78 | 79 | /** 80 | * Gets the path for a worktree (async version) 81 | */ 82 | async getWorktreePath(taskId: string): Promise { 83 | return getWorktreePath(taskId, this.context); 84 | } 85 | } 86 | -------------------------------------------------------------------------------- /src/core/metadata/index.ts: -------------------------------------------------------------------------------- 1 | /** 2 | * Metadata Schema Registry 3 | * 4 | * Central export point for metadata schema functionality 5 | */ 6 | 7 | export * from './types.js'; 8 | export * from './schema-service.js'; 9 | 10 | // Re-export commonly used functions for convenience 11 | export { 12 | getSchema, 13 | getStatusLabel, 14 | getStatusName, 15 | getTypeLabel, 16 | getTypeName, 17 | getPriorityLabel, 18 | getPriorityName, 19 | getWorkflowStateLabel, 20 | getWorkflowStateName, 21 | getAllowedValues, 22 | } from './schema-service.js'; 23 | -------------------------------------------------------------------------------- /src/core/metadata/normalizer-builder.ts: -------------------------------------------------------------------------------- 1 | /** 2 | * Schema-driven normalizer builder 3 | * 4 | * Creates efficient lookup maps for normalizing user input to canonical values 5 | * based on metadata schema definitions including aliases 6 | */ 7 | 8 | import type { MetadataValue } from './types.js'; 9 | 10 | /** 11 | * Builds a normalization map from metadata values 12 | * Maps all variations (name, label, emoji, aliases) to canonical name 13 | * 14 | * @param values Array of metadata values from schema 15 | * @returns Map for O(1) normalization lookups 16 | */ 17 | export function buildNormalizerMap(values: MetadataValue[]): Map { 18 | const normalizer = new Map(); 19 | 20 | for (const value of values) { 21 | // Add canonical name (exact match) 22 | normalizer.set(value.name.toLowerCase(), value.name); 23 | 24 | // Add label variation 25 | normalizer.set(value.label.toLowerCase(), value.name); 26 | 27 | // Add emoji variation if present 28 | if (value.emoji) { 29 | normalizer.set(value.emoji.toLowerCase(), value.name); 30 | } 31 | 32 | // Add all aliases 33 | if (value.aliases) { 34 | for (const alias of value.aliases) { 35 | normalizer.set(alias.toLowerCase(), value.name); 36 | } 37 | } 38 | } 39 | 40 | return normalizer; 41 | } 42 | 43 | /** 44 | * Creates a normalizer function using a pre-built map 45 | * 46 | * @param normalizerMap The lookup map built from schema 47 | * @param defaultValue The default value when input is null/undefined 48 | * @param fieldName The field name for error messages 49 | * @returns Normalizer function that validates and normalizes input 50 | */ 51 | export function createNormalizer( 52 | normalizerMap: Map, 53 | validValues: string[], 54 | defaultValue: string, 55 | fieldName: string 56 | ): (input: string | undefined | null) => string { 57 | return (input: string | undefined | null): string => { 58 | // Handle missing values - use default 59 | if (!input) { 60 | return defaultValue; 61 | } 62 | 63 | const lowerInput = input.toLowerCase().trim(); 64 | 65 | // Try exact match first (most common case) 66 | const normalized = normalizerMap.get(lowerInput); 67 | if (normalized) { 68 | return normalized; 69 | } 70 | 71 | // Try partial match as fallback 72 | // This handles cases like "feat" matching "feature" 73 | for (const [key, value] of normalizerMap.entries()) { 74 | if (key.includes(lowerInput) || lowerInput.includes(key)) { 75 | return value; 76 | } 77 | } 78 | 79 | // No match found - throw error with valid options 80 | throw new Error( 81 | `Invalid ${fieldName} "${input}". Valid options are: ${validValues.join(', ')}` 82 | ); 83 | }; 84 | } 85 | -------------------------------------------------------------------------------- /src/core/metadata/types.ts: -------------------------------------------------------------------------------- 1 | /** 2 | * Metadata Schema Types 3 | * 4 | * Core type definitions for the metadata schema registry 5 | */ 6 | 7 | export interface MetadataValue { 8 | name: string; // e.g., "in_progress" 9 | label: string; // e.g., "In Progress" 10 | emoji?: string; // Optional emoji for display 11 | icon?: string | null; // Optional Lucide icon name (null = no icon) 12 | template?: string; // Optional template file (for task types) 13 | aliases?: string[]; // TODO: Add support for input aliases 14 | } 15 | 16 | export interface MetadataEnum { 17 | values: MetadataValue[]; 18 | } 19 | 20 | export interface MetadataSchema { 21 | metadata: { 22 | enums: { 23 | workflowState: MetadataEnum; 24 | status: MetadataEnum; 25 | type: MetadataEnum; 26 | priority: MetadataEnum; 27 | phase: MetadataEnum; 28 | }; 29 | }; 30 | } 31 | 32 | // Type utilities for extracting enum values 33 | export type ExtractEnumNames = T['values'][number]['name']; 34 | export type ExtractEnumLabels = T['values'][number]['label']; 35 | -------------------------------------------------------------------------------- /src/core/paths/cache.ts: -------------------------------------------------------------------------------- 1 | /** 2 | * Simple cache implementation for path resolution 3 | * 4 | * Paths don't change during execution, so we can cache them 5 | * to avoid repeated git commands and file system checks 6 | */ 7 | 8 | interface CacheEntry { 9 | value: T; 10 | timestamp: number; 11 | } 12 | 13 | /** 14 | * Simple in-memory cache with optional TTL 15 | */ 16 | export class PathCache { 17 | private cache = new Map>(); 18 | private ttl: number; 19 | 20 | constructor(ttlMs: number = Number.POSITIVE_INFINITY) { 21 | this.ttl = ttlMs; 22 | } 23 | 24 | get(key: string): T | undefined { 25 | const entry = this.cache.get(key); 26 | if (!entry) return undefined; 27 | 28 | // Check if entry has expired 29 | if (this.ttl !== Number.POSITIVE_INFINITY && Date.now() - entry.timestamp > this.ttl) { 30 | this.cache.delete(key); 31 | return undefined; 32 | } 33 | 34 | return entry.value; 35 | } 36 | 37 | set(key: string, value: T): void { 38 | this.cache.set(key, { 39 | value, 40 | timestamp: Date.now(), 41 | }); 42 | } 43 | 44 | clear(): void { 45 | this.cache.clear(); 46 | } 47 | 48 | has(key: string): boolean { 49 | return this.get(key) !== undefined; 50 | } 51 | } 52 | 53 | // Global caches for different path types 54 | // These persist for the lifetime of the process 55 | export const pathContextCache = new PathCache(); 56 | export const directoryPathCache = new PathCache(); 57 | -------------------------------------------------------------------------------- /src/core/paths/index.ts: -------------------------------------------------------------------------------- 1 | /** 2 | * Path Resolution Module 3 | * 4 | * ⚠️ IMPORTANT: This is the ONLY module that should handle path resolution ⚠️ 5 | * 6 | * All path resolution logic for Scopecraft is centralized here. 7 | * DO NOT create path logic elsewhere in the codebase. 8 | */ 9 | 10 | // Main exports - these are what you should use 11 | export { 12 | // Core functions 13 | createPathContext, 14 | resolvePath, 15 | resolvePathWithPrecedence, 16 | resolveExistingPath, 17 | // Convenience functions 18 | getTemplatesPath, 19 | getModesPath, 20 | getTasksPath, 21 | getSessionsPath, 22 | getConfigPath, 23 | // Mode utilities 24 | findModeFiles, 25 | } from './path-resolver.js'; 26 | 27 | // Type exports 28 | export { 29 | PATH_TYPES, 30 | type PathType, 31 | type PathContext, 32 | type PathStrategy, 33 | } from './types.js'; 34 | 35 | // Strategy exports (rarely needed directly) 36 | export { 37 | pathStrategies, 38 | repoStrategy, 39 | centralizedStrategy, 40 | globalUserStrategy, 41 | } from './strategies.js'; 42 | 43 | // Migration helpers (temporary) 44 | export { 45 | legacyPathJoin, 46 | assertNoDirectPaths, 47 | isUnmigratedPath, 48 | logMigrationInstructions, 49 | } from './migration.js'; 50 | 51 | // Cache utilities (for performance) 52 | export { 53 | PathCache, 54 | pathContextCache, 55 | directoryPathCache, 56 | } from './cache.js'; 57 | -------------------------------------------------------------------------------- /src/core/paths/types.ts: -------------------------------------------------------------------------------- 1 | /** 2 | * Path type definitions for Scopecraft 3 | * 4 | * ⚠️ Adding a new path type? Add it HERE FIRST! ⚠️ 5 | */ 6 | 7 | /** 8 | * All valid path types in Scopecraft 9 | * Using const assertion for type safety 10 | */ 11 | export const PATH_TYPES = { 12 | TEMPLATES: 'templates', 13 | MODES: 'modes', 14 | TASKS: 'tasks', 15 | SESSIONS: 'sessions', 16 | CONFIG: 'config', 17 | SEARCH: 'search', 18 | } as const; 19 | 20 | /** 21 | * Type derived from PATH_TYPES values 22 | */ 23 | export type PathType = (typeof PATH_TYPES)[keyof typeof PATH_TYPES]; 24 | 25 | /** 26 | * Path context containing all necessary roots for resolution 27 | */ 28 | export interface PathContext { 29 | /** 30 | * Current working directory (where command is executed) 31 | * Could be main repo or a worktree 32 | */ 33 | executionRoot: string; 34 | 35 | /** 36 | * Main repository root (not worktree) 37 | * Used for shared resources and centralized storage encoding 38 | */ 39 | mainRepoRoot: string; 40 | 41 | /** 42 | * Current worktree root if in a worktree 43 | * undefined if in main repository 44 | */ 45 | worktreeRoot?: string; 46 | 47 | /** 48 | * User home directory 49 | * Used for global user preferences and centralized storage 50 | */ 51 | userHome: string; 52 | } 53 | 54 | /** 55 | * Strategy function type 56 | * Takes a context and returns a resolved path 57 | */ 58 | export type PathStrategy = (context: PathContext) => string; 59 | -------------------------------------------------------------------------------- /src/core/project-init.ts: -------------------------------------------------------------------------------- 1 | /** 2 | * Project Initialization 3 | * 4 | * Handles project structure initialization for workflow-based system 5 | */ 6 | 7 | import { ensureWorkflowDirectories } from './directory-utils.js'; 8 | import { initializeTemplates } from './template-manager.js'; 9 | import type { ProjectConfig } from './types.js'; 10 | 11 | /** 12 | * Initialize project structure 13 | */ 14 | export function initializeProjectStructure(projectRoot: string, config?: ProjectConfig): void { 15 | // Create workflow directories (handles both centralized and repo paths) 16 | ensureWorkflowDirectories(projectRoot, config); 17 | 18 | // Initialize templates in the repository with override if provided 19 | initializeTemplates(projectRoot, config?.override); 20 | } 21 | -------------------------------------------------------------------------------- /src/core/search/index.ts: -------------------------------------------------------------------------------- 1 | /** 2 | * Search module exports 3 | */ 4 | 5 | export { SearchService, getSearchService } from './search-service.js'; 6 | export { OramaAdapter } from './orama-adapter.js'; 7 | export { SearchIndexer } from './indexer.js'; 8 | export * from './types.js'; 9 | -------------------------------------------------------------------------------- /src/core/worktree/cache-manager.ts: -------------------------------------------------------------------------------- 1 | import type { CacheItem } from './types.js'; 2 | 3 | /** 4 | * Simple cache manager for git operations 5 | * Provides time-based caching with optional TTL (Time To Live) 6 | */ 7 | export class CacheManager { 8 | private cache: Map> = new Map(); 9 | private defaultTtl: number; 10 | 11 | /** 12 | * Creates a new cache manager 13 | * @param defaultTtl Default Time To Live in milliseconds (default: 30s) 14 | */ 15 | constructor(defaultTtl = 30000) { 16 | this.defaultTtl = defaultTtl; 17 | } 18 | 19 | /** 20 | * Gets a value from the cache 21 | * @param key Cache key 22 | * @returns The cached value or undefined if not found or expired 23 | */ 24 | get(key: string): T | undefined { 25 | const item = this.cache.get(key); 26 | 27 | // If item doesn't exist or is expired, return undefined 28 | if (!item || Date.now() - item.timestamp > this.defaultTtl) { 29 | return undefined; 30 | } 31 | 32 | return item.data as T; 33 | } 34 | 35 | /** 36 | * Stores a value in the cache 37 | * @param key Cache key 38 | * @param value Value to store 39 | */ 40 | set(key: string, value: T): void { 41 | this.cache.set(key, { 42 | data: value, 43 | timestamp: Date.now(), 44 | }); 45 | } 46 | 47 | /** 48 | * Gets a value from the cache, or computes and stores it if not found/expired 49 | * @param key Cache key 50 | * @param producer Function to produce the value if not in cache 51 | * @returns The cached or computed value 52 | */ 53 | async getOrCompute(key: string, producer: () => Promise): Promise { 54 | const cached = this.get(key); 55 | if (cached !== undefined) { 56 | return cached; 57 | } 58 | 59 | const value = await producer(); 60 | this.set(key, value); 61 | return value; 62 | } 63 | 64 | /** 65 | * Invalidates a specific cache entry 66 | * @param key Cache key to invalidate 67 | */ 68 | invalidate(key: string): void { 69 | this.cache.delete(key); 70 | } 71 | 72 | /** 73 | * Invalidates all cache entries 74 | */ 75 | clear(): void { 76 | this.cache.clear(); 77 | } 78 | 79 | /** 80 | * Creates a prefixed key 81 | * Useful for scoping cache entries to specific worktrees 82 | * @param prefix Prefix for the key 83 | * @param key The key to prefix 84 | * @returns Prefixed key 85 | */ 86 | createKey(prefix: string, key: string): string { 87 | return `${prefix}:${key}`; 88 | } 89 | } 90 | -------------------------------------------------------------------------------- /src/core/worktree/index.ts: -------------------------------------------------------------------------------- 1 | /** 2 | * Core worktree module exports 3 | */ 4 | 5 | // Type exports 6 | export * from './types.js'; 7 | 8 | // Service exports 9 | export { WorktreeService } from './worktree-service.js'; 10 | export { CacheManager } from './cache-manager.js'; 11 | -------------------------------------------------------------------------------- /src/integrations/channelcoder/constants.ts: -------------------------------------------------------------------------------- 1 | /** 2 | * ChannelCoder integration constants 3 | */ 4 | 5 | import { join } from 'node:path'; 6 | import type { IConfigurationManager } from '../../core/config/types.js'; 7 | import { WorktreePathResolver } from '../../core/environment/worktree-path-resolver.js'; 8 | import { TaskStoragePathEncoder } from '../../core/task-storage-path-encoder.js'; 9 | 10 | // Session storage configuration 11 | export const SESSION_STORAGE = { 12 | // Subdirectories under centralized storage 13 | SESSIONS_SUBDIR: 'sessions', // ChannelCoder session files 14 | LOGS_SUBDIR: 'logs', // Log files for autonomous tasks 15 | 16 | // File patterns 17 | INFO_FILE_SUFFIX: '.info.json', 18 | LOG_FILE_SUFFIX: '.log', 19 | } as const; 20 | 21 | /** 22 | * Get centralized session storage directories 23 | * All worktrees share the same session storage in ~/.scopecraft/projects/{encoded}/sessions/ 24 | */ 25 | export function getCentralizedSessionPaths(_config?: IConfigurationManager) { 26 | // Get main repository root to ensure all worktrees share the same storage 27 | // If interface provided, let WorktreePathResolver use its default getInstance() 28 | const resolver = new WorktreePathResolver(); 29 | const mainRepoRoot = resolver.getMainRepositoryRootSync(); 30 | 31 | // Use the same encoder as task storage for consistency 32 | const storageRoot = TaskStoragePathEncoder.getProjectStorageRoot(mainRepoRoot); 33 | 34 | return { 35 | baseDir: join(storageRoot, 'sessions'), 36 | sessionsDir: join(storageRoot, 'sessions', SESSION_STORAGE.SESSIONS_SUBDIR), 37 | logsDir: join(storageRoot, 'sessions', SESSION_STORAGE.LOGS_SUBDIR), 38 | }; 39 | } 40 | 41 | // Session types 42 | export const SESSION_TYPES = { 43 | AUTONOMOUS: 'autonomous-task', 44 | INTERACTIVE: 'interactive', 45 | PLANNING: 'planning', 46 | } as const; 47 | 48 | // Execution modes 49 | export const EXECUTION_MODES = { 50 | DETACHED: 'detached', 51 | DOCKER: 'docker', 52 | TMUX: 'tmux', 53 | INTERACTIVE: 'interactive', 54 | } as const; 55 | -------------------------------------------------------------------------------- /src/integrations/channelcoder/index.ts: -------------------------------------------------------------------------------- 1 | /** 2 | * ChannelCoder Integration Module 3 | * 4 | * Simple function-based wrapper around ChannelCoder SDK 5 | */ 6 | 7 | export { 8 | execute, 9 | createSession, 10 | loadSession, 11 | executeTmux, 12 | type ExecutionResult, 13 | type ScopecraftClaudeOptions, 14 | } from './client.js'; 15 | 16 | export { 17 | resolveModePromptPath, 18 | buildTaskData, 19 | } from './utils.js'; 20 | 21 | export { 22 | executeAutonomousTask, 23 | executeInteractiveTask, 24 | executePlan, 25 | } from './helpers.js'; 26 | 27 | export { 28 | ScopecraftSessionStorage, 29 | type ScopecraftSessionMetadata, 30 | } from './session-storage.js'; 31 | 32 | export { 33 | listAutonomousSessions, 34 | getSessionDetails, 35 | getSessionLogs, 36 | createSessionMonitor, 37 | type SessionStats, 38 | type SessionWithStats, 39 | type SessionDetails, 40 | type LogEntry, 41 | type MonitorEvent, 42 | } from './monitoring.js'; 43 | -------------------------------------------------------------------------------- /src/mcp/handler-wrapper.ts: -------------------------------------------------------------------------------- 1 | /** 2 | * MCP handler wrapper that applies parameter transformation 3 | */ 4 | import { transformMcpParams } from './parameter-transformer.js'; 5 | 6 | /** 7 | * Create an MCP handler that automatically transforms snake_case params to camelCase 8 | */ 9 | export function createMcpHandler( 10 | handler: (params: any) => Promise 11 | ): (params: unknown) => Promise { 12 | return async (rawParams: unknown) => { 13 | const transformedParams = transformMcpParams(rawParams); 14 | return handler(transformedParams); 15 | }; 16 | } 17 | -------------------------------------------------------------------------------- /src/mcp/handlers.ts: -------------------------------------------------------------------------------- 1 | /** 2 | * Re-export all handlers from the new location 3 | * This file is kept for backwards compatibility 4 | */ 5 | export * from './handlers/index.js'; 6 | -------------------------------------------------------------------------------- /src/mcp/handlers/shared/config-utils.ts: -------------------------------------------------------------------------------- 1 | /** 2 | * Shared configuration utilities for MCP handlers 3 | * Provides consistent config access across handlers 4 | */ 5 | 6 | import { existsSync, readFileSync } from 'node:fs'; 7 | import { join } from 'node:path'; 8 | import { ConfigurationManager } from '../../../core/config/configuration-manager.js'; 9 | // MIGRATION: Using centralized path resolver 10 | import { PATH_TYPES, createPathContext, resolvePath } from '../../../core/paths/index.js'; 11 | import type { ProjectConfig } from '../../../core/types.js'; 12 | 13 | /** 14 | * Get the project root from params or config 15 | * This is used by ALL handlers to get consistent project root 16 | */ 17 | export function getProjectRoot(params: { rootDir?: string }): string { 18 | const configManager = ConfigurationManager.getInstance(); 19 | return params.rootDir || configManager.getRootConfig().path; 20 | } 21 | 22 | /** 23 | * Get configuration manager instance 24 | * Provided for handlers that need direct config access 25 | */ 26 | export function getConfigManager(): ConfigurationManager { 27 | return ConfigurationManager.getInstance(); 28 | } 29 | 30 | /** 31 | * Load project configuration from .tasks/.config/project.json 32 | * Returns undefined if file doesn't exist or is invalid 33 | */ 34 | export function loadProjectConfig(projectRoot: string): ProjectConfig | undefined { 35 | // MIGRATION: Using centralized path resolver 36 | const context = createPathContext(projectRoot); 37 | const configDir = resolvePath(PATH_TYPES.CONFIG, context); 38 | const configPath = join(configDir, 'project.json'); 39 | 40 | if (!existsSync(configPath)) { 41 | return undefined; 42 | } 43 | 44 | try { 45 | const content = readFileSync(configPath, 'utf-8'); 46 | const config = JSON.parse(content) as ProjectConfig; 47 | return config; 48 | } catch (_error) { 49 | // Invalid JSON or read error - return undefined 50 | return undefined; 51 | } 52 | } 53 | -------------------------------------------------------------------------------- /src/mcp/handlers/shared/log-utils.ts: -------------------------------------------------------------------------------- 1 | /** 2 | * Shared log utilities for MCP handlers 3 | * Provides consistent log entry formatting 4 | */ 5 | 6 | /** 7 | * Append a timestamped log entry to existing log content 8 | */ 9 | export function appendTimestampedLogEntry(currentLog: string, entry: string): string { 10 | const timestamp = new Date().toISOString().split('T')[0]; 11 | const formattedEntry = `- ${timestamp}: ${entry}`; 12 | 13 | return currentLog ? `${currentLog}\n${formattedEntry}` : formattedEntry; 14 | } 15 | 16 | /** 17 | * Create a formatted log entry with timestamp 18 | */ 19 | export function createLogEntry(action: string, details?: string): string { 20 | const timestamp = new Date().toISOString().split('T')[0]; 21 | const entry = details ? `${action} - ${details}` : action; 22 | return `- ${timestamp}: ${entry}`; 23 | } 24 | 25 | /** 26 | * Parse log entries into structured format 27 | * Useful for analyzing or filtering logs 28 | */ 29 | export function parseLogEntries(log: string): Array<{ 30 | date: string; 31 | entry: string; 32 | }> { 33 | const lines = log.split('\n').filter((line) => line.trim()); 34 | const entries: Array<{ date: string; entry: string }> = []; 35 | 36 | for (const line of lines) { 37 | const match = line.match(/^-\s*(\d{4}-\d{2}-\d{2}):\s*(.+)$/); 38 | if (match) { 39 | entries.push({ 40 | date: match[1], 41 | entry: match[2].trim(), 42 | }); 43 | } 44 | } 45 | 46 | return entries; 47 | } 48 | -------------------------------------------------------------------------------- /src/mcp/handlers/shared/response-utils.ts: -------------------------------------------------------------------------------- 1 | /** 2 | * Shared response utilities for MCP handlers 3 | * Provides consistent response formatting across all handlers 4 | */ 5 | 6 | import type * as core from '../../../core/index.js'; 7 | import type { Task } from '../../schemas.js'; 8 | import { transformTask } from '../../transformers.js'; 9 | import type { McpResponse } from '../../types.js'; 10 | 11 | /** 12 | * Create a standardized success response 13 | */ 14 | export function createSuccessResponse(data: T, message: string): McpResponse { 15 | return { 16 | success: true, 17 | data, 18 | message, 19 | }; 20 | } 21 | 22 | /** 23 | * Create a standardized error response 24 | */ 25 | export function createErrorResponse(error: string, message?: string): McpResponse { 26 | return { 27 | success: false, 28 | error, 29 | message: message || 'Operation failed', 30 | }; 31 | } 32 | 33 | /** 34 | * Create a task response with normalized data 35 | * Used by create, update, and transform operations 36 | */ 37 | export async function createTaskResponse( 38 | projectRoot: string, 39 | task: core.Task, 40 | message: string, 41 | includeContent = true 42 | ): Promise> { 43 | try { 44 | const normalizedTask = await transformTask( 45 | projectRoot, 46 | task, 47 | includeContent, 48 | false // Never include subtasks in single task responses 49 | ); 50 | 51 | return { 52 | success: true, 53 | data: normalizedTask as unknown as T, 54 | message, 55 | }; 56 | } catch (error) { 57 | return createErrorResponse( 58 | error instanceof Error ? error.message : 'Failed to transform task', 59 | 'Task transformation failed' 60 | ); 61 | } 62 | } 63 | 64 | /** 65 | * Transform and return multiple tasks 66 | * Used by list operations 67 | */ 68 | export async function batchTransformTasks( 69 | projectRoot: string, 70 | tasks: core.Task[], 71 | includeContent = false 72 | ): Promise { 73 | const transformedTasks: Task[] = []; 74 | 75 | for (const task of tasks) { 76 | try { 77 | const normalizedTask = await transformTask( 78 | projectRoot, 79 | task, 80 | includeContent, 81 | false // Never include subtasks in list operations 82 | ); 83 | transformedTasks.push(normalizedTask); 84 | } catch (error) { 85 | console.error(`Failed to transform task ${task.metadata.id}:`, error); 86 | // Continue with other tasks 87 | } 88 | } 89 | 90 | return transformedTasks; 91 | } 92 | -------------------------------------------------------------------------------- /src/mcp/server.ts: -------------------------------------------------------------------------------- 1 | /** 2 | * MCP server implementation 3 | * Using the official MCP SDK with StreamableHTTP transport 4 | */ 5 | import { startHttpServer } from './http-server.js'; 6 | 7 | const DEFAULT_PORT = 3500; 8 | 9 | /** 10 | * Start the MCP server 11 | * @param port Port to listen on 12 | * @returns A Promise that resolves when the server is started 13 | */ 14 | export async function startServer(port: number = DEFAULT_PORT): Promise { 15 | console.log(`Starting MCP server with SDK implementation on port ${port}...`); 16 | return await startHttpServer(port, { verbose: true }); 17 | } 18 | -------------------------------------------------------------------------------- /src/mcp/stdio-server.ts: -------------------------------------------------------------------------------- 1 | /** 2 | * STDIO MCP server implementation 3 | * Uses the StdioServerTransport for terminal-based interaction 4 | */ 5 | import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'; 6 | import { createServerInstance } from './core-server.js'; 7 | 8 | /** 9 | * Start a STDIO MCP server 10 | * @param options Additional options 11 | * @returns A Promise that resolves when the server is closed 12 | */ 13 | export async function startStdioServer( 14 | options: { 15 | verbose?: boolean; 16 | } = {} 17 | ): Promise { 18 | // Create the transport 19 | const transport = new StdioServerTransport(); 20 | 21 | // No logging output to avoid interfering with MCP protocol 22 | 23 | // Create the server instance 24 | const server = createServerInstance(options); 25 | 26 | // Connect the transport to the server 27 | await server.connect(transport); 28 | } 29 | -------------------------------------------------------------------------------- /src/observability/logger.ts: -------------------------------------------------------------------------------- 1 | import { appendFileSync, mkdirSync } from 'node:fs'; 2 | import { join } from 'node:path'; 3 | 4 | /** 5 | * Simple logger for server-side operations 6 | * Logs to both console and file 7 | */ 8 | class SimpleLogger { 9 | private logDir: string; 10 | private logFile: string; 11 | 12 | constructor() { 13 | this.logDir = '/Users/davidpaquet/.scopecraft/logs'; 14 | this.logFile = join(this.logDir, `logs-${new Date().toISOString().split('T')[0]}.log`); 15 | mkdirSync(this.logDir, { recursive: true }); 16 | } 17 | 18 | private formatMessage(level: string, message: string, data?: any): string { 19 | const timestamp = new Date().toISOString(); 20 | const logEntry = { 21 | timestamp, 22 | level, 23 | message, 24 | data, 25 | }; 26 | return JSON.stringify(logEntry); 27 | } 28 | 29 | private writeToFile(logLine: string): void { 30 | try { 31 | appendFileSync(this.logFile, `${logLine}\n`); 32 | } catch (error) { 33 | console.error('Failed to write log:', error); 34 | } 35 | } 36 | 37 | info(message: string, data?: any): void { 38 | const logLine = this.formatMessage('INFO', message, data); 39 | console.log('[LOG]', logLine); 40 | this.writeToFile(logLine); 41 | } 42 | 43 | error(message: string, data?: any): void { 44 | const logLine = this.formatMessage('ERROR', message, data); 45 | console.error('[LOG]', logLine); 46 | this.writeToFile(logLine); 47 | } 48 | 49 | warn(message: string, data?: any): void { 50 | const logLine = this.formatMessage('WARN', message, data); 51 | console.warn('[LOG]', logLine); 52 | this.writeToFile(logLine); 53 | } 54 | 55 | debug(message: string, data?: any): void { 56 | const logLine = this.formatMessage('DEBUG', message, data); 57 | console.debug('[LOG]', logLine); 58 | this.writeToFile(logLine); 59 | } 60 | } 61 | 62 | export const logger = new SimpleLogger(); 63 | -------------------------------------------------------------------------------- /src/scripts/bun.d.ts: -------------------------------------------------------------------------------- 1 | // Type declarations for Bun runtime 2 | declare global { 3 | namespace globalThis { 4 | const Bun: { 5 | spawn: (cmd: string[], options?: { stdio?: any; cwd?: string }) => { 6 | exited: Promise; 7 | }; 8 | }; 9 | } 10 | } 11 | 12 | export {}; -------------------------------------------------------------------------------- /src/templates/01_feature.md: -------------------------------------------------------------------------------- 1 | # << FEATURE TITLE >> 2 | 3 | ## Description 4 | **What is this feature?** 5 | - 6 | 7 | **Why is it needed?** 8 | - 9 | 10 | **Who will use it?** 11 | - 12 | 13 | ## Acceptance Criteria 14 | - [ ] 15 | - [ ] 16 | - [ ] 17 | 18 | ## Implementation Plan 19 | ### Technical Approach 20 | - 21 | 22 | ### Sub-tasks 23 | - [ ] 24 | - [ ] 25 | - [ ] 26 | 27 | ## Dependencies 28 | - 29 | 30 | ## Implementation Log 31 | _Keep track of what was implemented and when_ 32 | - 33 | 34 | ## Notes 35 | - -------------------------------------------------------------------------------- /src/templates/02_bug.md: -------------------------------------------------------------------------------- 1 | # << BUG SUMMARY >> 2 | 3 | ## Description 4 | **What is the problem?** 5 | - 6 | 7 | **When does it occur?** 8 | - 9 | 10 | **Who is affected?** 11 | - 12 | 13 | ## Steps to Reproduce 14 | 1. 15 | 2. 16 | 3. 17 | 18 | ## Expected vs Actual Behavior 19 | **Expected:** 20 | - 21 | 22 | **Actual:** 23 | - 24 | 25 | ## Environment 26 | - OS: 27 | - Version: 28 | - Browser (if applicable): 29 | 30 | ## Possible Solution 31 | - 32 | 33 | ## Implementation Log 34 | _Track fix attempts and results_ 35 | - 36 | 37 | ## Notes 38 | - -------------------------------------------------------------------------------- /src/templates/03_chore.md: -------------------------------------------------------------------------------- 1 | # << CHORE TITLE >> 2 | 3 | ## Description 4 | **What needs to be done?** 5 | - 6 | 7 | **Why is this necessary?** 8 | - 9 | 10 | ## Tasks 11 | - [ ] 12 | - [ ] 13 | - [ ] 14 | 15 | ## Definition of Done 16 | - [ ] 17 | - [ ] 18 | 19 | ## Implementation Log 20 | _Track what was done and when_ 21 | - 22 | 23 | ## Notes 24 | - -------------------------------------------------------------------------------- /src/templates/04_documentation.md: -------------------------------------------------------------------------------- 1 | # << DOCUMENTATION TITLE >> 2 | 3 | ## Purpose 4 | **What is being documented?** 5 | - 6 | 7 | **Who is the audience?** 8 | - 9 | 10 | ## Content Outline 11 | 1. 12 | 2. 13 | 3. 14 | 15 | ## Key Points to Cover 16 | - 17 | - 18 | - 19 | 20 | ## References 21 | - 22 | 23 | ## Writing Log 24 | _Track documentation progress_ 25 | - 26 | 27 | ## Notes 28 | - -------------------------------------------------------------------------------- /src/templates/05_test.md: -------------------------------------------------------------------------------- 1 | # << TEST TITLE >> 2 | 3 | ## Test Objective 4 | **What are we testing?** 5 | - 6 | 7 | **Why is this test important?** 8 | - 9 | 10 | ## Test Type 11 | - [ ] Unit Test 12 | - [ ] Integration Test 13 | - [ ] End-to-End Test 14 | - [ ] Performance Test 15 | - [ ] Other: 16 | 17 | ## Test Cases 18 | ### Test Case 1: 19 | **Given:** 20 | **When:** 21 | **Then:** 22 | 23 | ### Test Case 2: 24 | **Given:** 25 | **When:** 26 | **Then:** 27 | 28 | ## Test Data Requirements 29 | - 30 | 31 | ## Success Criteria 32 | - [ ] 33 | - [ ] 34 | 35 | ## Implementation Log 36 | _Track test development progress_ 37 | - 38 | 39 | ## Notes 40 | - -------------------------------------------------------------------------------- /src/templates/06_spike.md: -------------------------------------------------------------------------------- 1 | # << SPIKE/RESEARCH TITLE >> 2 | 3 | ## Research Question 4 | **What do we need to find out?** 5 | - 6 | 7 | **Why is this important?** 8 | - 9 | 10 | ## Timebox 11 | - Duration: 12 | 13 | ## Approach 14 | 1. 15 | 2. 16 | 3. 17 | 18 | ## Options to Evaluate 19 | ### Option A: 20 | **Pros:** 21 | - 22 | 23 | **Cons:** 24 | - 25 | 26 | ### Option B: 27 | **Pros:** 28 | - 29 | 30 | **Cons:** 31 | - 32 | 33 | ## Success Criteria 34 | - [ ] 35 | - [ ] 36 | 37 | ## Research Log 38 | _Track research activities and progress_ 39 | - 40 | 41 | ## Findings 42 | - 43 | 44 | ## Recommendation 45 | - 46 | 47 | ## Next Steps 48 | - -------------------------------------------------------------------------------- /src/templates/modes/design/base.md: -------------------------------------------------------------------------------- 1 | --- 2 | input: 3 | taskId: string 4 | parentId?: string 5 | taskInstruction: string 6 | additionalInstructions?: string 7 | --- 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | You have a stake in this project's success. 17 | 18 | 19 | 20 | Create technical designs that balance ideal solutions with practical constraints. 21 | 22 | **Temporal Awareness**: Use `date` command when logging design decisions to maintain accurate timestamps and track design evolution. 23 | 24 | 25 | 26 | - Understand constraints first 27 | - Consider multiple options 28 | - Document trade-offs clearly 29 | - Plan for iteration 30 | 31 | 32 | 33 | 34 | 35 | 36 | Define problem → Explore solutions → Decide → Document 37 | 38 | 39 | 40 | 41 | Technical approach, trade-offs, implementation plan 42 | -------------------------------------------------------------------------------- /src/templates/modes/exploration/base.md: -------------------------------------------------------------------------------- 1 | --- 2 | input: 3 | taskId: string 4 | parentId?: string 5 | taskInstruction: string 6 | additionalInstructions?: string 7 | --- 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | You have a stake in this project's success. 17 | 18 | 19 | 20 | Understand the problem space deeply before proposing solutions. 21 | 22 | **Temporal Awareness**: Use `date` command when logging research activities to maintain accurate timestamps and track investigation progress. 23 | 24 | 25 | 26 | - Start broad, then focus 27 | - Question assumptions 28 | - Seek multiple perspectives 29 | - Document what you don't know 30 | 31 | 32 | 33 | 34 | 35 | 36 | Discover → Analyze → Synthesize → Recommend 37 | 38 | 39 | 40 | 41 | Research findings, recommendations, open questions 42 | -------------------------------------------------------------------------------- /src/templates/modes/guidance/project-setup.md: -------------------------------------------------------------------------------- 1 | # Project Setup Guidance 2 | 3 | 4 | 5 | 6 | ## Project Structure 7 | Define your standard directory layout and file organization. 8 | 9 | ## Naming Conventions 10 | - Tasks: How to name task files and IDs 11 | - Modes: Mode naming patterns 12 | - Files: Code file naming standards 13 | 14 | ## Tool Configuration 15 | List standard tools and their configuration. 16 | 17 | ## Development Workflow 18 | How your team works with tasks and modes. -------------------------------------------------------------------------------- /task-create: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | # Wrapper script for autonomous task creation 4 | # This delegates to the TypeScript implementation which uses the channelcoder SDK 5 | 6 | # Pass all arguments to the TypeScript implementation 7 | exec bun run scripts/task-creator-autonomous.ts "$@" -------------------------------------------------------------------------------- /tasks-ui/.cta.json: -------------------------------------------------------------------------------- 1 | { 2 | "projectName": "tasks-ui", 3 | "mode": "file-router", 4 | "typescript": true, 5 | "tailwind": true, 6 | "packageManager": "npm", 7 | "git": true, 8 | "version": 1, 9 | "framework": "react-cra", 10 | "chosenAddOns": [] 11 | } -------------------------------------------------------------------------------- /tasks-ui/.gitignore: -------------------------------------------------------------------------------- 1 | node_modules 2 | .DS_Store 3 | dist 4 | dist-ssr 5 | *.local 6 | 7 | *storybook.log 8 | storybook-static 9 | -------------------------------------------------------------------------------- /tasks-ui/.storybook/main.ts: -------------------------------------------------------------------------------- 1 | import type { StorybookConfig } from '@storybook/react-vite'; 2 | import { mergeConfig } from 'vite'; 3 | import path from 'path'; 4 | 5 | const config: StorybookConfig = { 6 | "stories": [ 7 | "../src/**/*.mdx", 8 | "../src/**/*.stories.@(js|jsx|mjs|ts|tsx)" 9 | ], 10 | "addons": [ 11 | "@storybook/addon-onboarding", 12 | "@storybook/addon-docs", 13 | "@storybook/addon-themes" 14 | ], 15 | "framework": { 16 | "name": "@storybook/react-vite", 17 | "options": {} 18 | }, 19 | async viteFinal(config) { 20 | // Add custom Vite configuration for Storybook 21 | return mergeConfig(config, { 22 | define: { 23 | // Define a global flag to indicate we're in Storybook 24 | 'import.meta.env.STORYBOOK': JSON.stringify(true), 25 | }, 26 | }); 27 | }, 28 | }; 29 | export default config; -------------------------------------------------------------------------------- /tasks-ui/.storybook/preview-head.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | -------------------------------------------------------------------------------- /tasks-ui/.storybook/preview.tsx: -------------------------------------------------------------------------------- 1 | import React from 'react' 2 | import type { Preview, Renderer, Decorator } from '@storybook/react-vite' 3 | import { withThemeByClassName } from '@storybook/addon-themes' 4 | import { RouterProvider, createRouter, createRootRoute } from '@tanstack/react-router' 5 | import '../src/styles.css' 6 | 7 | // Router decorator that creates a fresh router for each story 8 | const RouterDecorator: Decorator = (Story) => { 9 | const rootRoute = createRootRoute({ component: () => }); 10 | const routeTree = rootRoute; 11 | const router = createRouter({ routeTree }); 12 | return ; 13 | }; 14 | 15 | const preview: Preview = { 16 | parameters: { 17 | controls: { 18 | matchers: { 19 | color: /(background|color)$/i, 20 | date: /Date$/i, 21 | }, 22 | }, 23 | layout: 'padded', 24 | }, 25 | decorators: [ 26 | withThemeByClassName({ 27 | themes: { 28 | light: '', 29 | dark: 'dark', 30 | }, 31 | defaultTheme: 'light', 32 | }), 33 | RouterDecorator, 34 | (Story) => ( 35 |
36 | 37 |
38 | ), 39 | ] 40 | }; 41 | 42 | export default preview; -------------------------------------------------------------------------------- /tasks-ui/.vscode/settings.json: -------------------------------------------------------------------------------- 1 | { 2 | "files.watcherExclude": { 3 | "**/routeTree.gen.ts": true 4 | }, 5 | "search.exclude": { 6 | "**/routeTree.gen.ts": true 7 | }, 8 | "files.readonlyInclude": { 9 | "**/routeTree.gen.ts": true 10 | } 11 | } 12 | -------------------------------------------------------------------------------- /tasks-ui/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 12 | 13 | 14 | Create TanStack App - task-ui-2 15 | 16 | 17 |
18 | 19 | 20 | 21 | -------------------------------------------------------------------------------- /tasks-ui/package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "tasks-ui", 3 | "private": true, 4 | "type": "module", 5 | "scripts": { 6 | "dev": "echo 'Please run from root: bun run ui2:dev'", 7 | "dev:api": "echo 'Please run from root: bun run ui2:dev:api'", 8 | "dev:ui": "vite --port 3000", 9 | "start": "bun server.ts", 10 | "build": "vite build && tsc", 11 | "serve": "vite preview", 12 | "test": "vitest run", 13 | "test:watch": "vitest", 14 | "storybook": "storybook dev -p 6006", 15 | "build-storybook": "storybook build" 16 | }, 17 | "dependencies": { 18 | "@radix-ui/react-checkbox": "^1.3.1", 19 | "@radix-ui/react-dialog": "^1.1.13", 20 | "@radix-ui/react-dropdown-menu": "^2.1.15", 21 | "@radix-ui/react-select": "^2.2.5", 22 | "@radix-ui/react-slot": "^1.2.3", 23 | "@tailwindcss/vite": "^4.0.6", 24 | "@tanstack/react-query": "^5.79.0", 25 | "@tanstack/react-query-devtools": "^5.79.0", 26 | "@tanstack/react-router": "^1.114.3", 27 | "@tanstack/react-router-devtools": "^1.114.3", 28 | "@tanstack/react-table": "^8.21.3", 29 | "@tanstack/router-plugin": "^1.114.3", 30 | "class-variance-authority": "^0.7.1", 31 | "clsx": "^2.1.1", 32 | "cmdk": "^1.1.1", 33 | "date-fns": "^4.1.0", 34 | "lucide-react": "^0.510.0", 35 | "react": "^19.0.0", 36 | "react-dom": "^19.0.0", 37 | "react-markdown": "^10.1.0", 38 | "rehype-raw": "^7.0.0", 39 | "remark-gfm": "^4.0.1", 40 | "tailwind-merge": "^3.3.0", 41 | "tailwindcss": "^4.0.6", 42 | "zod": "^3.25.39" 43 | }, 44 | "devDependencies": { 45 | "@storybook/addon-docs": "^9.0.0", 46 | "@storybook/addon-onboarding": "^9.0.0", 47 | "@storybook/addon-themes": "^9.0.0", 48 | "@storybook/react-vite": "^9.0.0", 49 | "@tailwindcss/typography": "^0.5.16", 50 | "@testing-library/dom": "^10.4.0", 51 | "@testing-library/react": "^16.2.0", 52 | "@types/react": "^19.0.8", 53 | "@types/react-dom": "^19.0.3", 54 | "@vitejs/plugin-react": "^4.3.4", 55 | "@vitest/ui": "^3.1.4", 56 | "jsdom": "^26.0.0", 57 | "storybook": "^9.0.0", 58 | "typescript": "^5.7.2", 59 | "vite": "^6.1.0", 60 | "vitest": "^3.1.4", 61 | "web-vitals": "^4.2.4" 62 | } 63 | } 64 | -------------------------------------------------------------------------------- /tasks-ui/public/favicon.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/scopecraft/command/9325ea949ac6369ec773a2e68a2a733bc52df9d9/tasks-ui/public/favicon.ico -------------------------------------------------------------------------------- /tasks-ui/public/logo192.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/scopecraft/command/9325ea949ac6369ec773a2e68a2a733bc52df9d9/tasks-ui/public/logo192.png -------------------------------------------------------------------------------- /tasks-ui/public/logo512.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/scopecraft/command/9325ea949ac6369ec773a2e68a2a733bc52df9d9/tasks-ui/public/logo512.png -------------------------------------------------------------------------------- /tasks-ui/public/manifest.json: -------------------------------------------------------------------------------- 1 | { 2 | "short_name": "TanStack App", 3 | "name": "Create TanStack App Sample", 4 | "icons": [ 5 | { 6 | "src": "favicon.ico", 7 | "sizes": "64x64 32x32 24x24 16x16", 8 | "type": "image/x-icon" 9 | }, 10 | { 11 | "src": "logo192.png", 12 | "type": "image/png", 13 | "sizes": "192x192" 14 | }, 15 | { 16 | "src": "logo512.png", 17 | "type": "image/png", 18 | "sizes": "512x512" 19 | } 20 | ], 21 | "start_url": ".", 22 | "display": "standalone", 23 | "theme_color": "#000000", 24 | "background_color": "#ffffff" 25 | } 26 | -------------------------------------------------------------------------------- /tasks-ui/public/robots.txt: -------------------------------------------------------------------------------- 1 | # https://www.robotstxt.org/robotstxt.html 2 | User-agent: * 3 | Disallow: 4 | -------------------------------------------------------------------------------- /tasks-ui/src/components/CommandCenterWrapper.tsx: -------------------------------------------------------------------------------- 1 | import { useCommandCenter } from '../context/CommandCenterProvider'; 2 | import { CommandCenter } from './CommandCenter'; 3 | 4 | export function CommandCenterWrapper() { 5 | const { 6 | isOpen, 7 | closeCommandCenter, 8 | searchTasks, 9 | createTask, 10 | selectResult, 11 | isSearching, 12 | isCreating, 13 | searchError, 14 | createError, 15 | } = useCommandCenter(); 16 | 17 | return ( 18 | { 21 | if (!open) closeCommandCenter(); 22 | }} 23 | onSearch={searchTasks} 24 | onTaskCreate={createTask} 25 | onResultSelect={selectResult} 26 | isSearchLoading={isSearching} 27 | isCreateLoading={isCreating} 28 | error={searchError || createError} 29 | /> 30 | ); 31 | } 32 | -------------------------------------------------------------------------------- /tasks-ui/src/components/CommandPaletteWrapper.tsx: -------------------------------------------------------------------------------- 1 | // Legacy wrapper - now uses the new unified CommandCenter 2 | // This provides backward compatibility for existing imports 3 | import { useCommandCenter } from '../context/CommandCenterProvider'; 4 | import { CommandCenter } from './CommandCenter'; 5 | 6 | export function CommandPaletteWrapper() { 7 | const { 8 | isOpen, 9 | closeCommandCenter, 10 | searchTasks, 11 | createTask, 12 | selectResult, 13 | isSearching, 14 | isCreating, 15 | searchError, 16 | createError, 17 | } = useCommandCenter(); 18 | 19 | return ( 20 | { 23 | if (!open) closeCommandCenter(); 24 | }} 25 | onSearch={searchTasks} 26 | onTaskCreate={createTask} 27 | onResultSelect={selectResult} 28 | isSearchLoading={isSearching} 29 | isCreateLoading={isCreating} 30 | error={searchError || createError} 31 | // Start in create mode for backward compatibility 32 | initialQuery="+" 33 | /> 34 | ); 35 | } 36 | -------------------------------------------------------------------------------- /tasks-ui/src/components/claude/ConnectionStatus.tsx: -------------------------------------------------------------------------------- 1 | import { Button } from '../ui/button'; 2 | 3 | interface ConnectionStatusProps { 4 | isConnected: boolean; 5 | isConnecting: boolean; 6 | error: string | null; 7 | onConnect: () => void; 8 | onDisconnect: () => void; 9 | } 10 | 11 | /** 12 | * Connection status indicator component 13 | */ 14 | export function ConnectionStatus({ 15 | isConnected, 16 | isConnecting, 17 | error, 18 | onConnect, 19 | onDisconnect, 20 | }: ConnectionStatusProps) { 21 | return ( 22 |
23 |
24 | {/* Status */} 25 |
26 | Status:{' '} 27 | 32 | {isConnected ? '●' : isConnecting ? '◉' : '○'} 33 | {isConnected ? 'Connected' : isConnecting ? 'Connecting' : 'Disconnected'} 34 | 35 |
36 | 37 | {/* Error Display */} 38 | {error && ( 39 |
{error}
40 | )} 41 |
42 | 43 | {/* Connection Controls */} 44 |
45 | {!isConnected && !isConnecting && ( 46 | 49 | )} 50 | {isConnected && ( 51 | 54 | )} 55 |
56 |
57 | ); 58 | } 59 | -------------------------------------------------------------------------------- /tasks-ui/src/components/claude/MessageStream.tsx: -------------------------------------------------------------------------------- 1 | import type { Message } from '../../lib/claude-message-handler'; 2 | import { MessageDisplay } from '../task-detail/MessageDisplay'; 3 | 4 | interface MessageStreamProps { 5 | messages: Message[]; 6 | } 7 | 8 | /** 9 | * Message stream display component 10 | */ 11 | export function MessageStream({ messages }: MessageStreamProps) { 12 | return ( 13 |
14 | {messages.length === 0 ? ( 15 |
16 | No messages yet. Send a prompt to start the conversation. 17 |
18 | ) : ( 19 | messages.map((message) => ) 20 | )} 21 |
22 | ); 23 | } 24 | -------------------------------------------------------------------------------- /tasks-ui/src/components/claude/PromptForm.stories.tsx: -------------------------------------------------------------------------------- 1 | import type { Meta, StoryObj } from '@storybook/react'; 2 | import { useState } from 'react'; 3 | import { PromptForm } from './PromptForm'; 4 | 5 | const meta: Meta = { 6 | title: 'Claude/PromptForm', 7 | component: PromptForm, 8 | parameters: { 9 | layout: 'padded', 10 | }, 11 | args: { 12 | handleSubmit: () => {}, 13 | handleDisconnect: () => {}, 14 | setPrompt: () => {}, 15 | setContextId: () => {}, 16 | }, 17 | }; 18 | 19 | export default meta; 20 | type Story = StoryObj; 21 | 22 | // Interactive wrapper for realistic behavior 23 | function InteractivePromptForm(args: any) { 24 | const [prompt, setPrompt] = useState(args.prompt || ''); 25 | const [contextId, setContextId] = useState(args.contextId || ''); 26 | 27 | return ( 28 | 35 | ); 36 | } 37 | 38 | export const Default: Story = { 39 | args: { 40 | prompt: '', 41 | contextId: '', 42 | isConnecting: false, 43 | isConnected: true, 44 | }, 45 | render: (args) => , 46 | }; 47 | 48 | export const WithPrompt: Story = { 49 | args: { 50 | prompt: 'Can you help me implement a new feature for user authentication?', 51 | contextId: 'auth-feature-123', 52 | isConnecting: false, 53 | isConnected: true, 54 | }, 55 | render: (args) => , 56 | }; 57 | 58 | export const Connecting: Story = { 59 | args: { 60 | prompt: 'Please analyze the current task status', 61 | contextId: 'TASK-456', 62 | isConnecting: true, 63 | isConnected: false, 64 | }, 65 | render: (args) => , 66 | }; 67 | 68 | export const Disconnected: Story = { 69 | args: { 70 | prompt: '', 71 | contextId: '', 72 | isConnecting: false, 73 | isConnected: false, 74 | }, 75 | render: (args) => , 76 | }; 77 | 78 | export const WithPrefilledContext: Story = { 79 | args: { 80 | prompt: '', 81 | contextId: 'implement-v2-structure', 82 | isConnecting: false, 83 | isConnected: true, 84 | id: 'implement-v2-structure', // This would come from URL params 85 | }, 86 | render: (args) => , 87 | }; 88 | -------------------------------------------------------------------------------- /tasks-ui/src/components/claude/PromptForm.tsx: -------------------------------------------------------------------------------- 1 | import { Button } from '../ui/button'; 2 | 3 | interface PromptFormProps { 4 | prompt: string; 5 | setPrompt: (value: string) => void; 6 | contextId: string; 7 | setContextId: (value: string) => void; 8 | isConnecting: boolean; 9 | isConnected: boolean; 10 | id?: string; 11 | handleSubmit: (e: React.FormEvent) => void; 12 | handleDisconnect: () => void; 13 | } 14 | 15 | /** 16 | * Prompt input form component 17 | */ 18 | export function PromptForm({ 19 | prompt, 20 | setPrompt, 21 | contextId, 22 | setContextId, 23 | isConnecting, 24 | isConnected, 25 | id, 26 | handleSubmit, 27 | handleDisconnect, 28 | }: PromptFormProps) { 29 | return ( 30 |
31 | {/* Prompt Input */} 32 |
33 | 36 |