Compare commits
16 Commits
crunchyman
...
crunchyman
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
e350c315e3 | ||
|
|
c4cf104a30 | ||
|
|
37278292bc | ||
|
|
31f98c6521 | ||
|
|
b892d9743a | ||
|
|
9dc5e75760 | ||
|
|
16f4d4b932 | ||
|
|
7fef5ab488 | ||
|
|
38e416ef33 | ||
|
|
aa185b28b2 | ||
|
|
76618187f6 | ||
|
|
757fd478d2 | ||
|
|
6e6407f683 | ||
|
|
80f933cd82 | ||
|
|
2c3986c097 | ||
|
|
7086a77625 |
@@ -2,4 +2,4 @@
|
||||
"task-master-ai": patch
|
||||
---
|
||||
|
||||
Fix workflows
|
||||
Add CI for testing
|
||||
@@ -1,5 +0,0 @@
|
||||
---
|
||||
"task-master-ai": patch
|
||||
---
|
||||
|
||||
Added changeset config #39
|
||||
@@ -1,5 +0,0 @@
|
||||
---
|
||||
"task-master-ai": minor
|
||||
---
|
||||
|
||||
add github actions to automate github and npm releases
|
||||
@@ -1,5 +0,0 @@
|
||||
---
|
||||
"task-master-ai": minor
|
||||
---
|
||||
|
||||
Implement MCP server for all commands using tools.
|
||||
5
.changeset/red-lights-mix.md
Normal file
5
.changeset/red-lights-mix.md
Normal file
@@ -0,0 +1,5 @@
|
||||
---
|
||||
"task-master-ai": patch
|
||||
---
|
||||
|
||||
Fix github actions creating npm releases on next branch push
|
||||
@@ -1,5 +0,0 @@
|
||||
---
|
||||
"task-master-ai": patch
|
||||
---
|
||||
|
||||
Fix addTask tool `projectRoot not defined`
|
||||
@@ -1,5 +0,0 @@
|
||||
---
|
||||
"task-master-ai": patch
|
||||
---
|
||||
|
||||
fix mcp server not connecting to cursor
|
||||
61
.github/workflows/ci.yml
vendored
Normal file
61
.github/workflows/ci.yml
vendored
Normal file
@@ -0,0 +1,61 @@
|
||||
name: CI
|
||||
|
||||
on:
|
||||
push:
|
||||
branches:
|
||||
- main
|
||||
- next
|
||||
pull_request:
|
||||
branches:
|
||||
- main
|
||||
- next
|
||||
|
||||
permissions:
|
||||
contents: read
|
||||
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
with:
|
||||
fetch-depth: 0
|
||||
|
||||
- uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: 20
|
||||
cache: "npm"
|
||||
|
||||
- name: Cache node_modules
|
||||
uses: actions/cache@v4
|
||||
with:
|
||||
path: |
|
||||
node_modules
|
||||
*/*/node_modules
|
||||
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
|
||||
restore-keys: |
|
||||
${{ runner.os }}-node-
|
||||
|
||||
- name: Install Dependencies
|
||||
run: npm ci
|
||||
timeout-minutes: 2
|
||||
|
||||
- name: Run Tests
|
||||
run: |
|
||||
npm run test:coverage -- --coverageThreshold '{"global":{"branches":0,"functions":0,"lines":0,"statements":0}}' --detectOpenHandles --forceExit
|
||||
env:
|
||||
NODE_ENV: test
|
||||
CI: true
|
||||
FORCE_COLOR: 1
|
||||
timeout-minutes: 15
|
||||
|
||||
- name: Upload Test Results
|
||||
if: always()
|
||||
uses: actions/upload-artifact@v4
|
||||
with:
|
||||
name: test-results-node
|
||||
path: |
|
||||
test-results
|
||||
coverage
|
||||
junit.xml
|
||||
retention-days: 30
|
||||
15
.github/workflows/release.yml
vendored
15
.github/workflows/release.yml
vendored
@@ -3,7 +3,6 @@ on:
|
||||
push:
|
||||
branches:
|
||||
- main
|
||||
- next
|
||||
jobs:
|
||||
release:
|
||||
runs-on: ubuntu-latest
|
||||
@@ -15,9 +14,21 @@ jobs:
|
||||
- uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: 20
|
||||
cache: "npm"
|
||||
|
||||
- name: Cache node_modules
|
||||
uses: actions/cache@v4
|
||||
with:
|
||||
path: |
|
||||
node_modules
|
||||
*/*/node_modules
|
||||
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
|
||||
restore-keys: |
|
||||
${{ runner.os }}-node-
|
||||
|
||||
- name: Install Dependencies
|
||||
run: npm install
|
||||
run: npm ci
|
||||
timeout-minutes: 2
|
||||
|
||||
- name: Create Release Pull Request or Publish to npm
|
||||
uses: changesets/action@v1
|
||||
|
||||
27
CHANGELOG.md
Normal file
27
CHANGELOG.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# task-master-ai
|
||||
|
||||
## 0.10.1
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- [#80](https://github.com/eyaltoledano/claude-task-master/pull/80) [`aa185b2`](https://github.com/eyaltoledano/claude-task-master/commit/aa185b28b248b4ca93f9195b502e2f5187868eaa) Thanks [@Crunchyman-ralph](https://github.com/Crunchyman-ralph)! - Remove non-existent package `@model-context-protocol/sdk`
|
||||
|
||||
- [#45](https://github.com/eyaltoledano/claude-task-master/pull/45) [`757fd47`](https://github.com/eyaltoledano/claude-task-master/commit/757fd478d2e2eff8506ae746c3470c6088f4d944) Thanks [@Crunchyman-ralph](https://github.com/Crunchyman-ralph)! - Add license to repo
|
||||
|
||||
## 0.10.0
|
||||
|
||||
### Minor Changes
|
||||
|
||||
- [#44](https://github.com/eyaltoledano/claude-task-master/pull/44) [`eafdb47`](https://github.com/eyaltoledano/claude-task-master/commit/eafdb47418b444c03c092f653b438cc762d4bca8) Thanks [@Crunchyman-ralph](https://github.com/Crunchyman-ralph)! - add github actions to automate github and npm releases
|
||||
|
||||
- [#20](https://github.com/eyaltoledano/claude-task-master/pull/20) [`4eed269`](https://github.com/eyaltoledano/claude-task-master/commit/4eed2693789a444f704051d5fbb3ef8d460e4e69) Thanks [@Crunchyman-ralph](https://github.com/Crunchyman-ralph)! - Implement MCP server for all commands using tools.
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- [#44](https://github.com/eyaltoledano/claude-task-master/pull/44) [`44db895`](https://github.com/eyaltoledano/claude-task-master/commit/44db895303a9209416236e3d519c8a609ad85f61) Thanks [@Crunchyman-ralph](https://github.com/Crunchyman-ralph)! - Added changeset config #39
|
||||
|
||||
- [#50](https://github.com/eyaltoledano/claude-task-master/pull/50) [`257160a`](https://github.com/eyaltoledano/claude-task-master/commit/257160a9670b5d1942e7c623bd2c1a3fde7c06a0) Thanks [@Crunchyman-ralph](https://github.com/Crunchyman-ralph)! - Fix addTask tool `projectRoot not defined`
|
||||
|
||||
- [#57](https://github.com/eyaltoledano/claude-task-master/pull/57) [`9fd42ee`](https://github.com/eyaltoledano/claude-task-master/commit/9fd42eeafdc25a96cdfb70aa3af01f525d26b4bc) Thanks [@github-actions](https://github.com/apps/github-actions)! - fix mcp server not connecting to cursor
|
||||
|
||||
- [#48](https://github.com/eyaltoledano/claude-task-master/pull/48) [`5ec3651`](https://github.com/eyaltoledano/claude-task-master/commit/5ec3651e6459add7354910a86b3c4db4d12bc5d1) Thanks [@Crunchyman-ralph](https://github.com/Crunchyman-ralph)! - Fix workflows
|
||||
25
LICENSE
Normal file
25
LICENSE
Normal file
@@ -0,0 +1,25 @@
|
||||
Task Master License
|
||||
|
||||
MIT License
|
||||
|
||||
Copyright (c) 2025 — Eyal Toledano, Ralph Khreish
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
|
||||
"Commons Clause" License Condition v1.0
|
||||
|
||||
The Software is provided to you by the Licensor under the License (defined below), subject to the following condition:
|
||||
|
||||
Without limiting other conditions in the License, the grant of rights under the License will not include, and the License does not grant to you, the right to Sell the Software.
|
||||
|
||||
For purposes of the foregoing, "Sell" means practicing any or all of the rights granted to you under the License to provide the Software to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/support services related to the Software), as part of a product or service whose value derives, entirely or substantially, from the functionality of the Software. Any license notice or attribution required by the License must also include this Commons Clause License Condition notice.
|
||||
|
||||
Software: All Task Master associated files (including all files in the GitHub repository "claude-task-master" and in the npm package "task-master-ai").
|
||||
|
||||
License: MIT
|
||||
|
||||
Licensor: Eyal Toledano, Ralph Khreish
|
||||
90
LICENSE.md
Normal file
90
LICENSE.md
Normal file
@@ -0,0 +1,90 @@
|
||||
# Dual License
|
||||
|
||||
This project is licensed under two separate licenses:
|
||||
|
||||
1. [Business Source License 1.1](#business-source-license-11) (BSL 1.1) for commercial use of Task Master itself
|
||||
2. [Apache License 2.0](#apache-license-20) for all other uses
|
||||
|
||||
## Business Source License 1.1
|
||||
|
||||
Terms: https://mariadb.com/bsl11/
|
||||
|
||||
Licensed Work: Task Master AI
|
||||
Additional Use Grant: You may use Task Master AI to create and commercialize your own projects and products.
|
||||
|
||||
Change Date: 2025-03-30
|
||||
Change License: None
|
||||
|
||||
The Licensed Work is subject to the Business Source License 1.1. If you are interested in using the Licensed Work in a way that competes directly with Task Master, please contact the licensors.
|
||||
|
||||
### Licensor
|
||||
|
||||
- Eyal Toledano (GitHub: @eyaltoledano)
|
||||
- Ralph (GitHub: @Crunchyman-ralph)
|
||||
|
||||
### Commercial Use Restrictions
|
||||
|
||||
This license explicitly restricts certain commercial uses of Task Master AI to the Licensors listed above. Restricted commercial uses include:
|
||||
|
||||
1. Creating commercial products or services that directly compete with Task Master AI
|
||||
2. Selling Task Master AI itself as a service
|
||||
3. Offering Task Master AI's functionality as a commercial managed service
|
||||
4. Reselling or redistributing Task Master AI for a fee
|
||||
|
||||
### Explicitly Permitted Uses
|
||||
|
||||
The following uses are explicitly allowed under this license:
|
||||
|
||||
1. Using Task Master AI to create and commercialize your own projects
|
||||
2. Using Task Master AI in commercial environments for internal development
|
||||
3. Building and selling products or services that were created using Task Master AI
|
||||
4. Using Task Master AI for commercial development as long as you're not selling Task Master AI itself
|
||||
|
||||
### Additional Terms
|
||||
|
||||
1. The right to commercialize Task Master AI itself is exclusively reserved for the Licensors
|
||||
2. No party may create commercial products that directly compete with Task Master AI without explicit written permission
|
||||
3. Forks of this repository are subject to the same restrictions regarding direct competition
|
||||
4. Contributors agree that their contributions will be subject to this same dual licensing structure
|
||||
|
||||
## Apache License 2.0
|
||||
|
||||
For all uses other than those restricted above. See [APACHE-LICENSE](./APACHE-LICENSE) for the full license text.
|
||||
|
||||
### Permitted Use Definition
|
||||
|
||||
You may use Task Master AI for any purpose, including commercial purposes, as long as you are not:
|
||||
|
||||
1. Creating a direct competitor to Task Master AI
|
||||
2. Selling Task Master AI itself as a service
|
||||
3. Redistributing Task Master AI for a fee
|
||||
|
||||
### Requirements for Use
|
||||
|
||||
1. You must include appropriate copyright notices
|
||||
2. You must state significant changes made to the software
|
||||
3. You must preserve all license notices
|
||||
|
||||
## Questions and Commercial Licensing
|
||||
|
||||
For questions about licensing or to inquire about commercial use that may compete with Task Master, please contact:
|
||||
|
||||
- Eyal Toledano (GitHub: @eyaltoledano)
|
||||
- Ralph (GitHub: @Crunchyman-ralph)
|
||||
|
||||
## Examples
|
||||
|
||||
### ✅ Allowed Uses
|
||||
|
||||
- Using Task Master to create a commercial SaaS product
|
||||
- Using Task Master in your company for development
|
||||
- Creating and selling products that were built using Task Master
|
||||
- Using Task Master to generate code for commercial projects
|
||||
- Offering consulting services where you use Task Master
|
||||
|
||||
### ❌ Restricted Uses
|
||||
|
||||
- Creating a competing AI task management tool
|
||||
- Selling access to Task Master as a service
|
||||
- Creating a hosted version of Task Master
|
||||
- Reselling Task Master's functionality
|
||||
25
README.md
25
README.md
@@ -1,9 +1,32 @@
|
||||
# Task Master
|
||||
|
||||
[](https://github.com/eyaltoledano/claude-task-master/actions/workflows/ci.yml)
|
||||
[](LICENSE)
|
||||
[](https://badge.fury.io/js/task-master-ai)
|
||||
|
||||
### by [@eyaltoledano](https://x.com/eyaltoledano)
|
||||
|
||||
A task management system for AI-driven development with Claude, designed to work seamlessly with Cursor AI.
|
||||
|
||||
## Licensing
|
||||
|
||||
Task Master is licensed under the MIT License with Commons Clause. This means you can:
|
||||
|
||||
✅ **Allowed**:
|
||||
|
||||
- Use Task Master for any purpose (personal, commercial, academic)
|
||||
- Modify the code
|
||||
- Distribute copies
|
||||
- Create and sell products built using Task Master
|
||||
|
||||
❌ **Not Allowed**:
|
||||
|
||||
- Sell Task Master itself
|
||||
- Offer Task Master as a hosted service
|
||||
- Create competing products based on Task Master
|
||||
|
||||
See the [LICENSE](LICENSE) file for the complete license text.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Node.js 14.0.0 or higher
|
||||
@@ -385,7 +408,7 @@ task-master update-subtask --id=5.2 --prompt="Add rate limiting of 100 requests
|
||||
task-master update-subtask --id=<parentId.subtaskId> --prompt="<prompt>" --research
|
||||
```
|
||||
|
||||
Unlike the `update-task` command which replaces task information, the `update-subtask` command *appends* new information to the existing subtask details, marking it with a timestamp. This is useful for iteratively enhancing subtasks while preserving the original content.
|
||||
Unlike the `update-task` command which replaces task information, the `update-subtask` command _appends_ new information to the existing subtask details, marking it with a timestamp. This is useful for iteratively enhancing subtasks while preserving the original content.
|
||||
|
||||
### Generate Task Files
|
||||
|
||||
|
||||
@@ -1,5 +1,20 @@
|
||||
#!/usr/bin/env node
|
||||
|
||||
/**
|
||||
* Task Master
|
||||
* Copyright (c) 2025 Eyal Toledano, Ralph Khreish
|
||||
*
|
||||
* This software is licensed under the MIT License with Commons Clause.
|
||||
* You may use this software for any purpose, including commercial applications,
|
||||
* and modify and redistribute it freely, subject to the following restrictions:
|
||||
*
|
||||
* 1. You may not sell this software or offer it as a service.
|
||||
* 2. The origin of this software must not be misrepresented.
|
||||
* 3. Altered source versions must be plainly marked as such.
|
||||
*
|
||||
* For the full license text, see the LICENSE file in the root directory.
|
||||
*/
|
||||
|
||||
/**
|
||||
* Claude Task Master CLI
|
||||
* Main entry point for globally installed package
|
||||
|
||||
15
index.js
15
index.js
@@ -1,5 +1,20 @@
|
||||
#!/usr/bin/env node
|
||||
|
||||
/**
|
||||
* Task Master
|
||||
* Copyright (c) 2025 Eyal Toledano, Ralph Khreish
|
||||
*
|
||||
* This software is licensed under the MIT License with Commons Clause.
|
||||
* You may use this software for any purpose, including commercial applications,
|
||||
* and modify and redistribute it freely, subject to the following restrictions:
|
||||
*
|
||||
* 1. You may not sell this software or offer it as a service.
|
||||
* 2. The origin of this software must not be misrepresented.
|
||||
* 3. Altered source versions must be plainly marked as such.
|
||||
*
|
||||
* For the full license text, see the LICENSE file in the root directory.
|
||||
*/
|
||||
|
||||
/**
|
||||
* Claude Task Master
|
||||
* A task management system for AI-driven development with Claude
|
||||
|
||||
2
package-lock.json
generated
2
package-lock.json
generated
@@ -7,7 +7,7 @@
|
||||
"": {
|
||||
"name": "task-master-ai",
|
||||
"version": "0.9.30",
|
||||
"license": "MIT",
|
||||
"license": "(BSL-1.1 AND Apache-2.0)",
|
||||
"dependencies": {
|
||||
"@anthropic-ai/sdk": "^0.39.0",
|
||||
"boxen": "^8.0.1",
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "task-master-ai",
|
||||
"version": "0.9.30",
|
||||
"version": "0.10.1",
|
||||
"description": "A task management system for ambitious AI-driven development that doesn't overwhelm and confuse Cursor.",
|
||||
"main": "index.js",
|
||||
"type": "module",
|
||||
@@ -34,10 +34,9 @@
|
||||
"context"
|
||||
],
|
||||
"author": "Eyal Toledano",
|
||||
"license": "MIT",
|
||||
"license": "MIT WITH Commons-Clause",
|
||||
"dependencies": {
|
||||
"@anthropic-ai/sdk": "^0.39.0",
|
||||
"@model-context-protocol/sdk": "^1.20.5",
|
||||
"boxen": "^8.0.1",
|
||||
"chalk": "^4.1.2",
|
||||
"cli-table3": "^0.6.5",
|
||||
|
||||
@@ -1,5 +1,20 @@
|
||||
#!/usr/bin/env node
|
||||
|
||||
/**
|
||||
* Task Master
|
||||
* Copyright (c) 2025 Eyal Toledano, Ralph Khreish
|
||||
*
|
||||
* This software is licensed under the MIT License with Commons Clause.
|
||||
* You may use this software for any purpose, including commercial applications,
|
||||
* and modify and redistribute it freely, subject to the following restrictions:
|
||||
*
|
||||
* 1. You may not sell this software or offer it as a service.
|
||||
* 2. The origin of this software must not be misrepresented.
|
||||
* 3. Altered source versions must be plainly marked as such.
|
||||
*
|
||||
* For the full license text, see the LICENSE file in the root directory.
|
||||
*/
|
||||
|
||||
console.log('Starting task-master-ai...');
|
||||
|
||||
import fs from 'fs';
|
||||
|
||||
@@ -41,7 +41,8 @@ import {
|
||||
displayNextTask,
|
||||
displayTaskById,
|
||||
displayComplexityReport,
|
||||
getStatusWithColor
|
||||
getStatusWithColor,
|
||||
confirmTaskOverwrite
|
||||
} from './ui.js';
|
||||
|
||||
/**
|
||||
@@ -70,17 +71,34 @@ function registerCommands(programInstance) {
|
||||
.option('-i, --input <file>', 'Path to the PRD file (alternative to positional argument)')
|
||||
.option('-o, --output <file>', 'Output file path', 'tasks/tasks.json')
|
||||
.option('-n, --num-tasks <number>', 'Number of tasks to generate', '10')
|
||||
.option('-f, --force', 'Skip confirmation when overwriting existing tasks')
|
||||
.action(async (file, options) => {
|
||||
// Use input option if file argument not provided
|
||||
const inputFile = file || options.input;
|
||||
const defaultPrdPath = 'scripts/prd.txt';
|
||||
const numTasks = parseInt(options.numTasks, 10);
|
||||
const outputPath = options.output;
|
||||
const force = options.force || false;
|
||||
|
||||
// Helper function to check if tasks.json exists and confirm overwrite
|
||||
async function confirmOverwriteIfNeeded() {
|
||||
if (fs.existsSync(outputPath) && !force) {
|
||||
const shouldContinue = await confirmTaskOverwrite(outputPath);
|
||||
if (!shouldContinue) {
|
||||
console.log(chalk.yellow('Operation cancelled by user.'));
|
||||
return false;
|
||||
}
|
||||
}
|
||||
return true;
|
||||
}
|
||||
|
||||
// If no input file specified, check for default PRD location
|
||||
if (!inputFile) {
|
||||
if (fs.existsSync(defaultPrdPath)) {
|
||||
console.log(chalk.blue(`Using default PRD file: ${defaultPrdPath}`));
|
||||
const numTasks = parseInt(options.numTasks, 10);
|
||||
const outputPath = options.output;
|
||||
|
||||
// Check for existing tasks.json before proceeding
|
||||
if (!await confirmOverwriteIfNeeded()) return;
|
||||
|
||||
console.log(chalk.blue(`Generating ${numTasks} tasks...`));
|
||||
await parsePRD(defaultPrdPath, outputPath, numTasks);
|
||||
@@ -95,10 +113,12 @@ function registerCommands(programInstance) {
|
||||
chalk.cyan('Options:') + '\n' +
|
||||
' -i, --input <file> Path to the PRD file (alternative to positional argument)\n' +
|
||||
' -o, --output <file> Output file path (default: "tasks/tasks.json")\n' +
|
||||
' -n, --num-tasks <number> Number of tasks to generate (default: 10)\n\n' +
|
||||
' -n, --num-tasks <number> Number of tasks to generate (default: 10)\n' +
|
||||
' -f, --force Skip confirmation when overwriting existing tasks\n\n' +
|
||||
chalk.cyan('Example:') + '\n' +
|
||||
' task-master parse-prd requirements.txt --num-tasks 15\n' +
|
||||
' task-master parse-prd --input=requirements.txt\n\n' +
|
||||
' task-master parse-prd --input=requirements.txt\n' +
|
||||
' task-master parse-prd --force\n\n' +
|
||||
chalk.yellow('Note: This command will:') + '\n' +
|
||||
' 1. Look for a PRD file at scripts/prd.txt by default\n' +
|
||||
' 2. Use the file specified by --input or positional argument if provided\n' +
|
||||
@@ -108,8 +128,8 @@ function registerCommands(programInstance) {
|
||||
return;
|
||||
}
|
||||
|
||||
const numTasks = parseInt(options.numTasks, 10);
|
||||
const outputPath = options.output;
|
||||
// Check for existing tasks.json before proceeding with specified input file
|
||||
if (!await confirmOverwriteIfNeeded()) return;
|
||||
|
||||
console.log(chalk.blue(`Parsing PRD file: ${inputFile}`));
|
||||
console.log(chalk.blue(`Generating ${numTasks} tasks...`));
|
||||
|
||||
@@ -1061,6 +1061,33 @@ async function displayComplexityReport(reportPath) {
|
||||
));
|
||||
}
|
||||
|
||||
/**
|
||||
* Confirm overwriting existing tasks.json file
|
||||
* @param {string} tasksPath - Path to the tasks.json file
|
||||
* @returns {Promise<boolean>} - Promise resolving to true if user confirms, false otherwise
|
||||
*/
|
||||
async function confirmTaskOverwrite(tasksPath) {
|
||||
console.log(boxen(
|
||||
chalk.yellow('It looks like you\'ve already generated tasks for this project.\n') +
|
||||
chalk.yellow('Executing this command will overwrite any existing tasks.'),
|
||||
{ padding: 1, borderColor: 'yellow', borderStyle: 'round', margin: { top: 1 } }
|
||||
));
|
||||
|
||||
// Use dynamic import to get the readline module
|
||||
const readline = await import('readline');
|
||||
const rl = readline.createInterface({
|
||||
input: process.stdin,
|
||||
output: process.stdout
|
||||
});
|
||||
|
||||
const answer = await new Promise(resolve => {
|
||||
rl.question(chalk.cyan('Are you sure you wish to continue? (y/N): '), resolve);
|
||||
});
|
||||
rl.close();
|
||||
|
||||
return answer.toLowerCase() === 'y' || answer.toLowerCase() === 'yes';
|
||||
}
|
||||
|
||||
// Export UI functions
|
||||
export {
|
||||
displayBanner,
|
||||
@@ -1074,4 +1101,5 @@ export {
|
||||
displayNextTask,
|
||||
displayTaskById,
|
||||
displayComplexityReport,
|
||||
confirmTaskOverwrite
|
||||
};
|
||||
128
tasks/task_039.txt
Normal file
128
tasks/task_039.txt
Normal file
@@ -0,0 +1,128 @@
|
||||
# Task ID: 39
|
||||
# Title: Update Project Licensing to Dual License Structure
|
||||
# Status: done
|
||||
# Dependencies: None
|
||||
# Priority: high
|
||||
# Description: Replace the current MIT license with a dual license structure that protects commercial rights for project owners while allowing non-commercial use under an open source license.
|
||||
# Details:
|
||||
This task requires implementing a comprehensive licensing update across the project:
|
||||
|
||||
1. Remove all instances of the MIT license from the codebase, including any MIT license files, headers in source files, and references in documentation.
|
||||
|
||||
2. Create a dual license structure with:
|
||||
- Business Source License (BSL) 1.1 or similar for commercial use, explicitly stating that commercial rights are exclusively reserved for Ralph & Eyal
|
||||
- Apache 2.0 for non-commercial use, allowing the community to use, modify, and distribute the code for non-commercial purposes
|
||||
|
||||
3. Update the license field in package.json to reflect the dual license structure (e.g., "BSL 1.1 / Apache 2.0")
|
||||
|
||||
4. Add a clear, concise explanation of the licensing terms in the README.md, including:
|
||||
- A summary of what users can and cannot do with the code
|
||||
- Who holds commercial rights
|
||||
- How to obtain commercial use permission if needed
|
||||
- Links to the full license texts
|
||||
|
||||
5. Create a detailed LICENSE.md file that includes:
|
||||
- Full text of both licenses
|
||||
- Clear delineation between commercial and non-commercial use
|
||||
- Specific definitions of what constitutes commercial use
|
||||
- Any additional terms or clarifications specific to this project
|
||||
|
||||
6. Create a CONTRIBUTING.md file that explicitly states:
|
||||
- Contributors must agree that their contributions will be subject to the project's dual licensing
|
||||
- Commercial rights for all contributions are assigned to Ralph & Eyal
|
||||
- Guidelines for acceptable contributions
|
||||
|
||||
7. Ensure all source code files include appropriate license headers that reference the dual license structure.
|
||||
|
||||
# Test Strategy:
|
||||
To verify correct implementation, perform the following checks:
|
||||
|
||||
1. File verification:
|
||||
- Confirm the MIT license file has been removed
|
||||
- Verify LICENSE.md exists and contains both BSL and Apache 2.0 license texts
|
||||
- Confirm README.md includes the license section with clear explanation
|
||||
- Verify CONTRIBUTING.md exists with proper contributor guidelines
|
||||
- Check package.json for updated license field
|
||||
|
||||
2. Content verification:
|
||||
- Review LICENSE.md to ensure it properly describes the dual license structure with clear terms
|
||||
- Verify README.md license section is concise yet complete
|
||||
- Check that commercial rights are explicitly reserved for Ralph & Eyal in all relevant documents
|
||||
- Ensure CONTRIBUTING.md clearly explains the licensing implications for contributors
|
||||
|
||||
3. Legal review:
|
||||
- Have a team member not involved in the implementation review all license documents
|
||||
- Verify that the chosen BSL terms properly protect commercial interests
|
||||
- Confirm the Apache 2.0 implementation is correct and compatible with the BSL portions
|
||||
|
||||
4. Source code check:
|
||||
- Sample at least 10 source files to ensure they have updated license headers
|
||||
- Verify no MIT license references remain in any source files
|
||||
|
||||
5. Documentation check:
|
||||
- Ensure any documentation that mentioned licensing has been updated to reflect the new structure
|
||||
|
||||
# Subtasks:
|
||||
## 1. Remove MIT License and Create Dual License Files [done]
|
||||
### Dependencies: None
|
||||
### Description: Remove all MIT license references from the codebase and create the new license files for the dual license structure.
|
||||
### Details:
|
||||
Implementation steps:
|
||||
1. Scan the entire codebase to identify all instances of MIT license references (license files, headers in source files, documentation mentions).
|
||||
2. Remove the MIT license file and all direct references to it.
|
||||
3. Create a LICENSE.md file containing:
|
||||
- Full text of Business Source License (BSL) 1.1 with explicit commercial rights reservation for Ralph & Eyal
|
||||
- Full text of Apache 2.0 license for non-commercial use
|
||||
- Clear definitions of what constitutes commercial vs. non-commercial use
|
||||
- Specific terms for obtaining commercial use permission
|
||||
4. Create a CONTRIBUTING.md file that explicitly states the contribution terms:
|
||||
- Contributors must agree to the dual licensing structure
|
||||
- Commercial rights for all contributions are assigned to Ralph & Eyal
|
||||
- Guidelines for acceptable contributions
|
||||
|
||||
Testing approach:
|
||||
- Verify all MIT license references have been removed using a grep or similar search tool
|
||||
- Have legal review of the LICENSE.md and CONTRIBUTING.md files to ensure they properly protect commercial rights
|
||||
- Validate that the license files are properly formatted and readable
|
||||
|
||||
## 2. Update Source Code License Headers and Package Metadata [done]
|
||||
### Dependencies: 39.1
|
||||
### Description: Add appropriate dual license headers to all source code files and update package metadata to reflect the new licensing structure.
|
||||
### Details:
|
||||
Implementation steps:
|
||||
1. Create a template for the new license header that references the dual license structure (BSL 1.1 / Apache 2.0).
|
||||
2. Systematically update all source code files to include the new license header, replacing any existing MIT headers.
|
||||
3. Update the license field in package.json to "BSL 1.1 / Apache 2.0".
|
||||
4. Update any other metadata files (composer.json, setup.py, etc.) that contain license information.
|
||||
5. Verify that any build scripts or tools that reference licensing information are updated.
|
||||
|
||||
Testing approach:
|
||||
- Write a script to verify that all source files contain the new license header
|
||||
- Validate package.json and other metadata files have the correct license field
|
||||
- Ensure any build processes that depend on license information still function correctly
|
||||
- Run a sample build to confirm license information is properly included in any generated artifacts
|
||||
|
||||
## 3. Update Documentation and Create License Explanation [done]
|
||||
### Dependencies: 39.1, 39.2
|
||||
### Description: Update project documentation to clearly explain the dual license structure and create comprehensive licensing guidance.
|
||||
### Details:
|
||||
Implementation steps:
|
||||
1. Update the README.md with a clear, concise explanation of the licensing terms:
|
||||
- Summary of what users can and cannot do with the code
|
||||
- Who holds commercial rights (Ralph & Eyal)
|
||||
- How to obtain commercial use permission
|
||||
- Links to the full license texts
|
||||
2. Create a dedicated LICENSING.md or similar document with detailed explanations of:
|
||||
- The rationale behind the dual licensing approach
|
||||
- Detailed examples of what constitutes commercial vs. non-commercial use
|
||||
- FAQs addressing common licensing questions
|
||||
3. Update any other documentation references to licensing throughout the project.
|
||||
4. Create visual aids (if appropriate) to help users understand the licensing structure.
|
||||
5. Ensure all documentation links to licensing information are updated.
|
||||
|
||||
Testing approach:
|
||||
- Have non-technical stakeholders review the documentation for clarity and understanding
|
||||
- Verify all links to license files work correctly
|
||||
- Ensure the explanation is comprehensive but concise enough for users to understand quickly
|
||||
- Check that the documentation correctly addresses the most common use cases and questions
|
||||
|
||||
102
tasks/task_040.txt
Normal file
102
tasks/task_040.txt
Normal file
@@ -0,0 +1,102 @@
|
||||
# Task ID: 40
|
||||
# Title: Implement Project Funding Documentation and Support Infrastructure
|
||||
# Status: in-progress
|
||||
# Dependencies: None
|
||||
# Priority: medium
|
||||
# Description: Create FUNDING.yml for GitHub Sponsors integration that outlines all financial support options for the Task Master project.
|
||||
# Details:
|
||||
This task involves creating a FUNDING.yml file to enable and manage funding options for the Task Master project:
|
||||
|
||||
**FUNDING.yml file**:
|
||||
- Create a .github/FUNDING.yml file following GitHub's specifications
|
||||
- Include configuration for multiple funding platforms:
|
||||
- GitHub Sponsors (primary if available)
|
||||
- Open Collective
|
||||
- Patreon
|
||||
- Ko-fi
|
||||
- Liberapay
|
||||
- Custom funding URLs (project website donation page)
|
||||
- Research and reference successful implementation patterns from Vue.js, React, and TypeScript projects
|
||||
- Ensure the FUNDING.yml contains sufficient information to guide users on how to support the project
|
||||
- Include comments within the YAML file to provide context for each funding option
|
||||
|
||||
The implementation should maintain consistent branding and messaging with the rest of the Task Master project. Research at least 5 successful open source projects to identify best practices in funding configuration.
|
||||
|
||||
# Test Strategy:
|
||||
Testing should verify the technical implementation of the FUNDING.yml file:
|
||||
|
||||
1. **FUNDING.yml validation**:
|
||||
- Verify the file is correctly placed in the .github directory
|
||||
- Validate YAML syntax using a linter
|
||||
- Test that GitHub correctly displays funding options on the repository page
|
||||
- Verify all links to external funding platforms are functional
|
||||
|
||||
2. **User experience testing**:
|
||||
- Test the complete funding workflow from a potential supporter's perspective
|
||||
- Verify the process is intuitive and barriers to contribution are minimized
|
||||
- Check that the Sponsor button appears correctly on GitHub
|
||||
- Ensure all funding platform links resolve to the correct destinations
|
||||
- Gather feedback from 2-3 potential users on clarity and ease of use
|
||||
|
||||
# Subtasks:
|
||||
## 1. Research and Create FUNDING.yml File [done]
|
||||
### Dependencies: None
|
||||
### Description: Research successful funding configurations and create the .github/FUNDING.yml file for GitHub Sponsors integration and other funding platforms.
|
||||
### Details:
|
||||
Implementation steps:
|
||||
1. Create the .github directory at the project root if it doesn't exist
|
||||
2. Research funding configurations from 5 successful open source projects (Vue.js, React, TypeScript, etc.)
|
||||
3. Document the patterns and approaches used in these projects
|
||||
4. Create the FUNDING.yml file with the following platforms:
|
||||
- GitHub Sponsors (primary)
|
||||
- Open Collective
|
||||
- Patreon
|
||||
- Ko-fi
|
||||
- Liberapay
|
||||
- Custom donation URL for the project website
|
||||
5. Validate the YAML syntax using a linter
|
||||
6. Test the file by pushing to a test branch and verifying the Sponsor button appears correctly on GitHub
|
||||
|
||||
Testing approach:
|
||||
- Validate YAML syntax using yamllint or similar tool
|
||||
- Test on GitHub by checking if the Sponsor button appears in the repository
|
||||
- Verify each funding link resolves to the correct destination
|
||||
|
||||
## 4. Add Documentation Comments to FUNDING.yml [pending]
|
||||
### Dependencies: 40.1
|
||||
### Description: Add comprehensive comments within the FUNDING.yml file to provide context and guidance for each funding option.
|
||||
### Details:
|
||||
Implementation steps:
|
||||
1. Add a header comment explaining the purpose of the file
|
||||
2. For each funding platform entry, add comments that explain:
|
||||
- What the platform is
|
||||
- How funds are processed on this platform
|
||||
- Any specific benefits of using this platform
|
||||
- Brief instructions for potential sponsors
|
||||
3. Include a comment about how sponsors will be acknowledged
|
||||
4. Add information about fund allocation (maintenance, new features, infrastructure)
|
||||
5. Ensure comments follow YAML comment syntax and don't break the file structure
|
||||
|
||||
Testing approach:
|
||||
- Validate that the YAML file still passes linting with comments added
|
||||
- Verify the file still functions correctly on GitHub
|
||||
- Have at least one team member review the comments for clarity and completeness
|
||||
|
||||
## 5. Integrate Funding Information in Project README [pending]
|
||||
### Dependencies: 40.1, 40.4
|
||||
### Description: Add a section to the project README that highlights the funding options and directs users to the Sponsor button.
|
||||
### Details:
|
||||
Implementation steps:
|
||||
1. Create a 'Support the Project' or 'Sponsorship' section in the README.md
|
||||
2. Explain briefly why financial support matters for the project
|
||||
3. Direct users to the GitHub Sponsor button
|
||||
4. Mention the alternative funding platforms available
|
||||
5. Include a brief note on how funds will be used
|
||||
6. Add any relevant funding badges (e.g., Open Collective, GitHub Sponsors)
|
||||
|
||||
Testing approach:
|
||||
- Review the README section for clarity and conciseness
|
||||
- Verify all links work correctly
|
||||
- Ensure the section is appropriately visible but doesn't overshadow project information
|
||||
- Check that badges render correctly
|
||||
|
||||
89
tasks/task_041.txt
Normal file
89
tasks/task_041.txt
Normal file
@@ -0,0 +1,89 @@
|
||||
# Task ID: 41
|
||||
# Title: Implement GitHub Actions CI Workflow for Task Master
|
||||
# Status: pending
|
||||
# Dependencies: None
|
||||
# Priority: high
|
||||
# Description: Create a streamlined CI workflow file (ci.yml) that efficiently tests the Task Master codebase using GitHub Actions.
|
||||
# Details:
|
||||
Create a GitHub Actions workflow file at `.github/workflows/ci.yml` with the following specifications:
|
||||
|
||||
1. Configure the workflow to trigger on:
|
||||
- Push events to any branch
|
||||
- Pull request events targeting any branch
|
||||
|
||||
2. Core workflow configuration:
|
||||
- Use Ubuntu latest as the primary testing environment
|
||||
- Use Node.js 20.x (LTS) for consistency with the project
|
||||
- Focus on single environment for speed and simplicity
|
||||
|
||||
3. Configure workflow steps to:
|
||||
- Checkout the repository using actions/checkout@v4
|
||||
- Set up Node.js using actions/setup-node@v4 with npm caching
|
||||
- Install dependencies with 'npm ci'
|
||||
- Run tests with 'npm run test:coverage'
|
||||
|
||||
4. Implement efficient caching:
|
||||
- Cache node_modules using actions/cache@v4
|
||||
- Use package-lock.json hash for cache key
|
||||
- Implement proper cache restoration keys
|
||||
|
||||
5. Ensure proper timeouts:
|
||||
- 2 minutes for dependency installation
|
||||
- Appropriate timeout for test execution
|
||||
|
||||
6. Artifact handling:
|
||||
- Upload test results and coverage reports
|
||||
- Use consistent naming for artifacts
|
||||
- Retain artifacts for 30 days
|
||||
|
||||
# Test Strategy:
|
||||
To verify correct implementation of the GitHub Actions CI workflow:
|
||||
|
||||
1. Manual verification:
|
||||
- Check that the file is correctly placed at `.github/workflows/ci.yml`
|
||||
- Verify the YAML syntax is valid
|
||||
- Confirm all required configurations are present
|
||||
|
||||
2. Functional testing:
|
||||
- Push a commit to verify the workflow triggers
|
||||
- Create a PR to verify the workflow runs on pull requests
|
||||
- Verify test coverage reports are generated and uploaded
|
||||
- Confirm caching is working effectively
|
||||
|
||||
3. Performance testing:
|
||||
- Verify cache hits reduce installation time
|
||||
- Confirm workflow completes within expected timeframe
|
||||
- Check artifact upload and download speeds
|
||||
|
||||
# Subtasks:
|
||||
## 1. Create Basic GitHub Actions Workflow [pending]
|
||||
### Dependencies: None
|
||||
### Description: Set up the foundational GitHub Actions workflow file with proper triggers and Node.js setup
|
||||
### Details:
|
||||
1. Create `.github/workflows/ci.yml`
|
||||
2. Configure workflow name and triggers
|
||||
3. Set up Ubuntu runner and Node.js 20.x
|
||||
4. Implement checkout and Node.js setup actions
|
||||
5. Configure npm caching
|
||||
6. Test basic workflow functionality
|
||||
|
||||
## 2. Implement Test and Coverage Steps [pending]
|
||||
### Dependencies: 41.1
|
||||
### Description: Add test execution and coverage reporting to the workflow
|
||||
### Details:
|
||||
1. Add dependency installation with proper timeout
|
||||
2. Configure test execution with coverage
|
||||
3. Set up test results and coverage artifacts
|
||||
4. Verify artifact upload functionality
|
||||
5. Test the complete workflow
|
||||
|
||||
## 3. Optimize Workflow Performance [pending]
|
||||
### Dependencies: 41.1, 41.2
|
||||
### Description: Implement caching and performance optimizations
|
||||
### Details:
|
||||
1. Set up node_modules caching
|
||||
2. Configure cache key strategy
|
||||
3. Implement proper timeout values
|
||||
4. Test caching effectiveness
|
||||
5. Document performance improvements
|
||||
|
||||
132
tasks/tasks.json
132
tasks/tasks.json
@@ -2164,6 +2164,138 @@
|
||||
"priority": "high",
|
||||
"details": "Implement a version check mechanism that runs automatically with every command execution:\n\n1. Create a new module (e.g., `versionChecker.js`) that will:\n - Fetch the latest version from npm registry using the npm registry API (https://registry.npmjs.org/task-master-ai/latest)\n - Compare it with the current installed version (from package.json)\n - Store the last check timestamp to avoid excessive API calls (check once per day)\n - Cache the result to minimize network requests\n\n2. The notification should:\n - Use colored text (e.g., yellow background with black text) to be noticeable\n - Include the current version and latest version\n - Show the exact upgrade command: 'npm i task-master-ai@latest'\n - Be displayed at the beginning or end of command output, not interrupting the main content\n - Include a small separator line to distinguish it from command output\n\n3. Implementation considerations:\n - Handle network failures gracefully (don't block command execution if version check fails)\n - Add a configuration option to disable update checks if needed\n - Ensure the check is lightweight and doesn't significantly impact command performance\n - Consider using a package like 'semver' for proper version comparison\n - Implement a cooldown period (e.g., only check once per day) to avoid excessive API calls\n\n4. The version check should be integrated into the main command execution flow so it runs for all commands automatically.",
|
||||
"testStrategy": "1. Manual testing:\n - Install an older version of the package\n - Run various commands and verify the update notification appears\n - Update to the latest version and confirm the notification no longer appears\n - Test with network disconnected to ensure graceful handling of failures\n\n2. Unit tests:\n - Mock the npm registry response to test different scenarios:\n - When a newer version exists\n - When using the latest version\n - When the registry is unavailable\n - Test the version comparison logic with various version strings\n - Test the cooldown/caching mechanism works correctly\n\n3. Integration tests:\n - Create a test that runs a command and verifies the notification appears in the expected format\n - Test that the notification appears for all commands\n - Verify the notification doesn't interfere with normal command output\n\n4. Edge cases to test:\n - Pre-release versions (alpha/beta)\n - Very old versions\n - When package.json is missing or malformed\n - When npm registry returns unexpected data"
|
||||
},
|
||||
{
|
||||
"id": 39,
|
||||
"title": "Update Project Licensing to Dual License Structure",
|
||||
"description": "Replace the current MIT license with a dual license structure that protects commercial rights for project owners while allowing non-commercial use under an open source license.",
|
||||
"status": "done",
|
||||
"dependencies": [],
|
||||
"priority": "high",
|
||||
"details": "This task requires implementing a comprehensive licensing update across the project:\n\n1. Remove all instances of the MIT license from the codebase, including any MIT license files, headers in source files, and references in documentation.\n\n2. Create a dual license structure with:\n - Business Source License (BSL) 1.1 or similar for commercial use, explicitly stating that commercial rights are exclusively reserved for Ralph & Eyal\n - Apache 2.0 for non-commercial use, allowing the community to use, modify, and distribute the code for non-commercial purposes\n\n3. Update the license field in package.json to reflect the dual license structure (e.g., \"BSL 1.1 / Apache 2.0\")\n\n4. Add a clear, concise explanation of the licensing terms in the README.md, including:\n - A summary of what users can and cannot do with the code\n - Who holds commercial rights\n - How to obtain commercial use permission if needed\n - Links to the full license texts\n\n5. Create a detailed LICENSE.md file that includes:\n - Full text of both licenses\n - Clear delineation between commercial and non-commercial use\n - Specific definitions of what constitutes commercial use\n - Any additional terms or clarifications specific to this project\n\n6. Create a CONTRIBUTING.md file that explicitly states:\n - Contributors must agree that their contributions will be subject to the project's dual licensing\n - Commercial rights for all contributions are assigned to Ralph & Eyal\n - Guidelines for acceptable contributions\n\n7. Ensure all source code files include appropriate license headers that reference the dual license structure.",
|
||||
"testStrategy": "To verify correct implementation, perform the following checks:\n\n1. File verification:\n - Confirm the MIT license file has been removed\n - Verify LICENSE.md exists and contains both BSL and Apache 2.0 license texts\n - Confirm README.md includes the license section with clear explanation\n - Verify CONTRIBUTING.md exists with proper contributor guidelines\n - Check package.json for updated license field\n\n2. Content verification:\n - Review LICENSE.md to ensure it properly describes the dual license structure with clear terms\n - Verify README.md license section is concise yet complete\n - Check that commercial rights are explicitly reserved for Ralph & Eyal in all relevant documents\n - Ensure CONTRIBUTING.md clearly explains the licensing implications for contributors\n\n3. Legal review:\n - Have a team member not involved in the implementation review all license documents\n - Verify that the chosen BSL terms properly protect commercial interests\n - Confirm the Apache 2.0 implementation is correct and compatible with the BSL portions\n\n4. Source code check:\n - Sample at least 10 source files to ensure they have updated license headers\n - Verify no MIT license references remain in any source files\n\n5. Documentation check:\n - Ensure any documentation that mentioned licensing has been updated to reflect the new structure",
|
||||
"subtasks": [
|
||||
{
|
||||
"id": 1,
|
||||
"title": "Remove MIT License and Create Dual License Files",
|
||||
"description": "Remove all MIT license references from the codebase and create the new license files for the dual license structure.",
|
||||
"dependencies": [],
|
||||
"details": "Implementation steps:\n1. Scan the entire codebase to identify all instances of MIT license references (license files, headers in source files, documentation mentions).\n2. Remove the MIT license file and all direct references to it.\n3. Create a LICENSE.md file containing:\n - Full text of Business Source License (BSL) 1.1 with explicit commercial rights reservation for Ralph & Eyal\n - Full text of Apache 2.0 license for non-commercial use\n - Clear definitions of what constitutes commercial vs. non-commercial use\n - Specific terms for obtaining commercial use permission\n4. Create a CONTRIBUTING.md file that explicitly states the contribution terms:\n - Contributors must agree to the dual licensing structure\n - Commercial rights for all contributions are assigned to Ralph & Eyal\n - Guidelines for acceptable contributions\n\nTesting approach:\n- Verify all MIT license references have been removed using a grep or similar search tool\n- Have legal review of the LICENSE.md and CONTRIBUTING.md files to ensure they properly protect commercial rights\n- Validate that the license files are properly formatted and readable",
|
||||
"status": "done",
|
||||
"parentTaskId": 39
|
||||
},
|
||||
{
|
||||
"id": 2,
|
||||
"title": "Update Source Code License Headers and Package Metadata",
|
||||
"description": "Add appropriate dual license headers to all source code files and update package metadata to reflect the new licensing structure.",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "Implementation steps:\n1. Create a template for the new license header that references the dual license structure (BSL 1.1 / Apache 2.0).\n2. Systematically update all source code files to include the new license header, replacing any existing MIT headers.\n3. Update the license field in package.json to \"BSL 1.1 / Apache 2.0\".\n4. Update any other metadata files (composer.json, setup.py, etc.) that contain license information.\n5. Verify that any build scripts or tools that reference licensing information are updated.\n\nTesting approach:\n- Write a script to verify that all source files contain the new license header\n- Validate package.json and other metadata files have the correct license field\n- Ensure any build processes that depend on license information still function correctly\n- Run a sample build to confirm license information is properly included in any generated artifacts",
|
||||
"status": "done",
|
||||
"parentTaskId": 39
|
||||
},
|
||||
{
|
||||
"id": 3,
|
||||
"title": "Update Documentation and Create License Explanation",
|
||||
"description": "Update project documentation to clearly explain the dual license structure and create comprehensive licensing guidance.",
|
||||
"dependencies": [
|
||||
1,
|
||||
2
|
||||
],
|
||||
"details": "Implementation steps:\n1. Update the README.md with a clear, concise explanation of the licensing terms:\n - Summary of what users can and cannot do with the code\n - Who holds commercial rights (Ralph & Eyal)\n - How to obtain commercial use permission\n - Links to the full license texts\n2. Create a dedicated LICENSING.md or similar document with detailed explanations of:\n - The rationale behind the dual licensing approach\n - Detailed examples of what constitutes commercial vs. non-commercial use\n - FAQs addressing common licensing questions\n3. Update any other documentation references to licensing throughout the project.\n4. Create visual aids (if appropriate) to help users understand the licensing structure.\n5. Ensure all documentation links to licensing information are updated.\n\nTesting approach:\n- Have non-technical stakeholders review the documentation for clarity and understanding\n- Verify all links to license files work correctly\n- Ensure the explanation is comprehensive but concise enough for users to understand quickly\n- Check that the documentation correctly addresses the most common use cases and questions",
|
||||
"status": "done",
|
||||
"parentTaskId": 39
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": 40,
|
||||
"title": "Implement Project Funding Documentation and Support Infrastructure",
|
||||
"description": "Create FUNDING.yml for GitHub Sponsors integration that outlines all financial support options for the Task Master project.",
|
||||
"status": "in-progress",
|
||||
"dependencies": [],
|
||||
"priority": "medium",
|
||||
"details": "This task involves creating a FUNDING.yml file to enable and manage funding options for the Task Master project:\n\n**FUNDING.yml file**:\n - Create a .github/FUNDING.yml file following GitHub's specifications\n - Include configuration for multiple funding platforms:\n - GitHub Sponsors (primary if available)\n - Open Collective\n - Patreon\n - Ko-fi\n - Liberapay\n - Custom funding URLs (project website donation page)\n - Research and reference successful implementation patterns from Vue.js, React, and TypeScript projects\n - Ensure the FUNDING.yml contains sufficient information to guide users on how to support the project\n - Include comments within the YAML file to provide context for each funding option\n\nThe implementation should maintain consistent branding and messaging with the rest of the Task Master project. Research at least 5 successful open source projects to identify best practices in funding configuration.",
|
||||
"testStrategy": "Testing should verify the technical implementation of the FUNDING.yml file:\n\n1. **FUNDING.yml validation**:\n - Verify the file is correctly placed in the .github directory\n - Validate YAML syntax using a linter\n - Test that GitHub correctly displays funding options on the repository page\n - Verify all links to external funding platforms are functional\n\n2. **User experience testing**:\n - Test the complete funding workflow from a potential supporter's perspective\n - Verify the process is intuitive and barriers to contribution are minimized\n - Check that the Sponsor button appears correctly on GitHub\n - Ensure all funding platform links resolve to the correct destinations\n - Gather feedback from 2-3 potential users on clarity and ease of use",
|
||||
"subtasks": [
|
||||
{
|
||||
"id": 1,
|
||||
"title": "Research and Create FUNDING.yml File",
|
||||
"description": "Research successful funding configurations and create the .github/FUNDING.yml file for GitHub Sponsors integration and other funding platforms.",
|
||||
"dependencies": [],
|
||||
"details": "Implementation steps:\n1. Create the .github directory at the project root if it doesn't exist\n2. Research funding configurations from 5 successful open source projects (Vue.js, React, TypeScript, etc.)\n3. Document the patterns and approaches used in these projects\n4. Create the FUNDING.yml file with the following platforms:\n - GitHub Sponsors (primary)\n - Open Collective\n - Patreon\n - Ko-fi\n - Liberapay\n - Custom donation URL for the project website\n5. Validate the YAML syntax using a linter\n6. Test the file by pushing to a test branch and verifying the Sponsor button appears correctly on GitHub\n\nTesting approach:\n- Validate YAML syntax using yamllint or similar tool\n- Test on GitHub by checking if the Sponsor button appears in the repository\n- Verify each funding link resolves to the correct destination",
|
||||
"status": "done",
|
||||
"parentTaskId": 40
|
||||
},
|
||||
{
|
||||
"id": 4,
|
||||
"title": "Add Documentation Comments to FUNDING.yml",
|
||||
"description": "Add comprehensive comments within the FUNDING.yml file to provide context and guidance for each funding option.",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "Implementation steps:\n1. Add a header comment explaining the purpose of the file\n2. For each funding platform entry, add comments that explain:\n - What the platform is\n - How funds are processed on this platform\n - Any specific benefits of using this platform\n - Brief instructions for potential sponsors\n3. Include a comment about how sponsors will be acknowledged\n4. Add information about fund allocation (maintenance, new features, infrastructure)\n5. Ensure comments follow YAML comment syntax and don't break the file structure\n\nTesting approach:\n- Validate that the YAML file still passes linting with comments added\n- Verify the file still functions correctly on GitHub\n- Have at least one team member review the comments for clarity and completeness",
|
||||
"status": "pending",
|
||||
"parentTaskId": 40
|
||||
},
|
||||
{
|
||||
"id": 5,
|
||||
"title": "Integrate Funding Information in Project README",
|
||||
"description": "Add a section to the project README that highlights the funding options and directs users to the Sponsor button.",
|
||||
"dependencies": [
|
||||
1,
|
||||
4
|
||||
],
|
||||
"details": "Implementation steps:\n1. Create a 'Support the Project' or 'Sponsorship' section in the README.md\n2. Explain briefly why financial support matters for the project\n3. Direct users to the GitHub Sponsor button\n4. Mention the alternative funding platforms available\n5. Include a brief note on how funds will be used\n6. Add any relevant funding badges (e.g., Open Collective, GitHub Sponsors)\n\nTesting approach:\n- Review the README section for clarity and conciseness\n- Verify all links work correctly\n- Ensure the section is appropriately visible but doesn't overshadow project information\n- Check that badges render correctly",
|
||||
"status": "pending",
|
||||
"parentTaskId": 40
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": 41,
|
||||
"title": "Implement GitHub Actions CI Workflow for Cross-Platform Testing",
|
||||
"description": "Create a CI workflow file (ci.yml) that tests the codebase across multiple Node.js versions and operating systems using GitHub Actions.",
|
||||
"status": "pending",
|
||||
"dependencies": [],
|
||||
"priority": "high",
|
||||
"details": "Create a GitHub Actions workflow file at `.github/workflows/ci.yml` with the following specifications:\n\n1. Configure the workflow to trigger on:\n - Push events to any branch\n - Pull request events targeting any branch\n\n2. Implement a matrix strategy that tests across:\n - Node.js versions: 18.x, 20.x, and 22.x\n - Operating systems: Ubuntu-latest and Windows-latest\n\n3. Include proper Git configuration steps:\n - Set Git user name to 'GitHub Actions'\n - Set Git email to 'github-actions@github.com'\n\n4. Configure workflow steps to:\n - Checkout the repository using actions/checkout@v3\n - Set up Node.js using actions/setup-node@v3 with the matrix version\n - Use npm for package management (not pnpm)\n - Install dependencies with 'npm ci'\n - Run linting with 'npm run lint' (if available)\n - Run tests with 'npm test'\n - Run build process with 'npm run build'\n\n5. Implement concurrency controls to:\n - Cancel in-progress workflows when new commits are pushed to the same PR\n - Use a concurrency group based on the GitHub ref and workflow name\n\n6. Add proper caching for npm dependencies to speed up workflow runs\n\n7. Ensure the workflow includes appropriate timeouts to prevent hung jobs",
|
||||
"testStrategy": "To verify correct implementation of the GitHub Actions CI workflow:\n\n1. Manual verification:\n - Check that the file is correctly placed at `.github/workflows/ci.yml`\n - Verify the YAML syntax is valid using a YAML linter\n - Confirm all required configurations (triggers, matrix, steps) are present\n\n2. Functional testing:\n - Push a commit to a feature branch to confirm the workflow triggers\n - Create a PR to verify the workflow runs on pull requests\n - Verify the workflow successfully runs on both Ubuntu and Windows\n - Confirm tests run against all three Node.js versions (18, 20, 22)\n - Test concurrency by pushing multiple commits to the same PR rapidly\n\n3. Edge case testing:\n - Introduce a failing test and verify the workflow reports failure\n - Test with a large dependency tree to verify caching works correctly\n - Verify the workflow handles non-ASCII characters in file paths correctly (particularly on Windows)\n\n4. Check workflow logs to ensure:\n - Git configuration is applied correctly\n - Dependencies are installed with npm (not pnpm)\n - All matrix combinations run independently\n - Concurrency controls cancel redundant workflow runs",
|
||||
"subtasks": [
|
||||
{
|
||||
"id": 1,
|
||||
"title": "Create Basic GitHub Actions Workflow Structure",
|
||||
"description": "Set up the foundational GitHub Actions workflow file with triggers, checkout, and Node.js setup using matrix strategy",
|
||||
"dependencies": [],
|
||||
"details": "1. Create `.github/workflows/` directory if it doesn't exist\n2. Create a new file `ci.yml` inside this directory\n3. Define the workflow name at the top of the file\n4. Configure triggers for push events to any branch and pull request events targeting any branch\n5. Set up the matrix strategy for Node.js versions (18.x, 20.x, 22.x) and operating systems (Ubuntu-latest, Windows-latest)\n6. Configure the job to checkout the repository using actions/checkout@v3\n7. Set up Node.js using actions/setup-node@v3 with the matrix version\n8. Add proper caching for npm dependencies\n9. Test the workflow by pushing the file to a test branch and verifying it triggers correctly\n10. Verify that the matrix builds are running on all specified Node versions and operating systems",
|
||||
"status": "pending",
|
||||
"parentTaskId": 41
|
||||
},
|
||||
{
|
||||
"id": 2,
|
||||
"title": "Implement Build and Test Steps with Git Configuration",
|
||||
"description": "Add the core build and test steps to the workflow, including Git configuration, dependency installation, and execution of lint, test, and build commands",
|
||||
"dependencies": [
|
||||
1
|
||||
],
|
||||
"details": "1. Add Git configuration steps to set user name to 'GitHub Actions' and email to 'github-actions@github.com'\n2. Add step to install dependencies with 'npm ci'\n3. Add conditional step to run linting with 'npm run lint' if available\n4. Add step to run tests with 'npm test'\n5. Add step to run build process with 'npm run build'\n6. Ensure each step has appropriate names for clear visibility in GitHub Actions UI\n7. Add appropriate error handling and continue-on-error settings where needed\n8. Test the workflow by pushing a change and verifying all build steps execute correctly\n9. Verify that the workflow correctly runs on both Ubuntu and Windows environments\n10. Ensure that all commands use the correct syntax for cross-platform compatibility",
|
||||
"status": "pending",
|
||||
"parentTaskId": 41
|
||||
},
|
||||
{
|
||||
"id": 3,
|
||||
"title": "Add Workflow Optimization Features",
|
||||
"description": "Implement concurrency controls, timeouts, and other optimization features to improve workflow efficiency and reliability",
|
||||
"dependencies": [
|
||||
1,
|
||||
2
|
||||
],
|
||||
"details": "1. Implement concurrency controls to cancel in-progress workflows when new commits are pushed to the same PR\n2. Define a concurrency group based on the GitHub ref and workflow name\n3. Add appropriate timeouts to prevent hung jobs (typically 30-60 minutes depending on project complexity)\n4. Add status badges to the README.md file to show build status\n5. Optimize the workflow by adding appropriate 'if' conditions to skip unnecessary steps\n6. Add job summary outputs to provide clear information about the build results\n7. Test the concurrency feature by pushing multiple commits in quick succession to a PR\n8. Verify that old workflow runs are canceled when new commits are pushed\n9. Test timeout functionality by temporarily adding a long-running step\n10. Document the CI workflow in project documentation, explaining what it does and how to troubleshoot common issues",
|
||||
"status": "pending",
|
||||
"parentTaskId": 41
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -25,6 +25,7 @@ const mockIsTaskDependentOn = jest.fn().mockReturnValue(false);
|
||||
const mockCreate = jest.fn(); // Mock for Anthropic messages.create
|
||||
const mockChatCompletionsCreate = jest.fn(); // Mock for Perplexity chat.completions.create
|
||||
const mockGetAvailableAIModel = jest.fn(); // <<<<< Added mock function
|
||||
const mockPromptYesNo = jest.fn(); // Mock for confirmation prompt
|
||||
|
||||
// Mock fs module
|
||||
jest.mock('fs', () => ({
|
||||
@@ -76,6 +77,7 @@ jest.mock('../../scripts/modules/utils.js', () => ({
|
||||
readComplexityReport: jest.fn(), // <<<<< Added mock
|
||||
findTaskInComplexityReport: jest.fn(), // <<<<< Added mock
|
||||
truncate: jest.fn((str, len) => str.slice(0, len)), // <<<<< Added mock
|
||||
promptYesNo: mockPromptYesNo, // Added mock for confirmation prompt
|
||||
}));
|
||||
|
||||
// Mock AI services - Update this mock
|
||||
@@ -129,6 +131,19 @@ jest.mock('../../scripts/modules/task-manager.js', () => {
|
||||
// Create a simplified version of parsePRD for testing
|
||||
const testParsePRD = async (prdPath, outputPath, numTasks) => {
|
||||
try {
|
||||
// Check if the output file already exists
|
||||
if (mockExistsSync(outputPath)) {
|
||||
const confirmOverwrite = await mockPromptYesNo(
|
||||
`Warning: ${outputPath} already exists. Overwrite?`,
|
||||
false
|
||||
);
|
||||
|
||||
if (!confirmOverwrite) {
|
||||
console.log(`Operation cancelled. ${outputPath} was not modified.`);
|
||||
return null;
|
||||
}
|
||||
}
|
||||
|
||||
const prdContent = mockReadFileSync(prdPath, 'utf8');
|
||||
const tasks = await mockCallClaude(prdContent, prdPath, numTasks);
|
||||
const dir = mockDirname(outputPath);
|
||||
@@ -563,6 +578,7 @@ describe('Task Manager Module', () => {
|
||||
mockDirname.mockReturnValue('tasks');
|
||||
mockCallClaude.mockResolvedValue(sampleClaudeResponse);
|
||||
mockGenerateTaskFiles.mockResolvedValue(undefined);
|
||||
mockPromptYesNo.mockResolvedValue(true); // Default to "yes" for confirmation
|
||||
});
|
||||
|
||||
test('should parse a PRD file and generate tasks', async () => {
|
||||
@@ -586,8 +602,13 @@ describe('Task Manager Module', () => {
|
||||
});
|
||||
|
||||
test('should create the tasks directory if it does not exist', async () => {
|
||||
// Mock existsSync to return false to simulate directory doesn't exist
|
||||
mockExistsSync.mockReturnValueOnce(false);
|
||||
// Mock existsSync to return false specifically for the directory check
|
||||
// but true for the output file check (so we don't trigger confirmation path)
|
||||
mockExistsSync.mockImplementation((path) => {
|
||||
if (path === 'tasks/tasks.json') return false; // Output file doesn't exist
|
||||
if (path === 'tasks') return false; // Directory doesn't exist
|
||||
return true; // Default for other paths
|
||||
});
|
||||
|
||||
// Call the function
|
||||
await testParsePRD('path/to/prd.txt', 'tasks/tasks.json', 3);
|
||||
@@ -624,6 +645,83 @@ describe('Task Manager Module', () => {
|
||||
// Verify generateTaskFiles was called
|
||||
expect(mockGenerateTaskFiles).toHaveBeenCalledWith('tasks/tasks.json', 'tasks');
|
||||
});
|
||||
|
||||
test('should prompt for confirmation when tasks.json already exists', async () => {
|
||||
// Setup mocks to simulate tasks.json already exists
|
||||
mockExistsSync.mockImplementation((path) => {
|
||||
if (path === 'tasks/tasks.json') return true; // Output file exists
|
||||
if (path === 'tasks') return true; // Directory exists
|
||||
return false;
|
||||
});
|
||||
|
||||
// Call the function
|
||||
await testParsePRD('path/to/prd.txt', 'tasks/tasks.json', 3);
|
||||
|
||||
// Verify prompt was called with expected message
|
||||
expect(mockPromptYesNo).toHaveBeenCalledWith(
|
||||
'Warning: tasks/tasks.json already exists. Overwrite?',
|
||||
false
|
||||
);
|
||||
|
||||
// Verify the file was written after confirmation
|
||||
expect(mockWriteJSON).toHaveBeenCalledWith('tasks/tasks.json', sampleClaudeResponse);
|
||||
});
|
||||
|
||||
test('should not overwrite tasks.json when user declines confirmation', async () => {
|
||||
// Setup mocks to simulate tasks.json already exists
|
||||
mockExistsSync.mockImplementation((path) => {
|
||||
if (path === 'tasks/tasks.json') return true; // Output file exists
|
||||
if (path === 'tasks') return true; // Directory exists
|
||||
return false;
|
||||
});
|
||||
|
||||
// Mock user declining the confirmation
|
||||
mockPromptYesNo.mockResolvedValueOnce(false);
|
||||
|
||||
// Mock console.log to capture output
|
||||
const mockConsoleLog = jest.spyOn(console, 'log').mockImplementation(() => {});
|
||||
|
||||
// Call the function
|
||||
const result = await testParsePRD('path/to/prd.txt', 'tasks/tasks.json', 3);
|
||||
|
||||
// Verify prompt was called
|
||||
expect(mockPromptYesNo).toHaveBeenCalledWith(
|
||||
'Warning: tasks/tasks.json already exists. Overwrite?',
|
||||
false
|
||||
);
|
||||
|
||||
// Verify the file was NOT written
|
||||
expect(mockWriteJSON).not.toHaveBeenCalled();
|
||||
|
||||
// Verify appropriate message was logged
|
||||
expect(mockConsoleLog).toHaveBeenCalledWith(
|
||||
'Operation cancelled. tasks/tasks.json was not modified.'
|
||||
);
|
||||
|
||||
// Verify result is null when operation is cancelled
|
||||
expect(result).toBeNull();
|
||||
|
||||
// Restore console.log
|
||||
mockConsoleLog.mockRestore();
|
||||
});
|
||||
|
||||
test('should not prompt for confirmation when tasks.json does not exist', async () => {
|
||||
// Setup mocks to simulate tasks.json does not exist
|
||||
mockExistsSync.mockImplementation((path) => {
|
||||
if (path === 'tasks/tasks.json') return false; // Output file doesn't exist
|
||||
if (path === 'tasks') return true; // Directory exists
|
||||
return false;
|
||||
});
|
||||
|
||||
// Call the function
|
||||
await testParsePRD('path/to/prd.txt', 'tasks/tasks.json', 3);
|
||||
|
||||
// Verify prompt was NOT called
|
||||
expect(mockPromptYesNo).not.toHaveBeenCalled();
|
||||
|
||||
// Verify the file was written without confirmation
|
||||
expect(mockWriteJSON).toHaveBeenCalledWith('tasks/tasks.json', sampleClaudeResponse);
|
||||
});
|
||||
});
|
||||
|
||||
describe.skip('updateTasks function', () => {
|
||||
|
||||
Reference in New Issue
Block a user