@eskoubar95/spec 0.1.0

package/dist/commands/init.d.ts

@@ -0,0 +1,5 @@
+/**
+ * Initializes a new SDD project
+ */
+export declare function runInit(): Promise<void>;
+//# sourceMappingURL=init.d.ts.map

package/dist/commands/init.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"init.d.ts","sourceRoot":"","sources":["../../src/commands/init.ts"],"names":[],"mappings":"AAMA;;GAEG;AACH,wBAAsB,OAAO,IAAI,OAAO,CAAC,IAAI,CAAC,CAmD7C"}

package/dist/commands/init.js

@@ -0,0 +1,55 @@
+import path from 'path';
+import { copyTemplate, createLinearConfig } from '../lib/copy-template.js';
+import { initGit } from '../lib/git.js';
+import { promptInit } from '../lib/prompts.js';
+import fs from 'fs-extra';
+/**
+ * Initializes a new SDD project
+ */
+export async function runInit() {
+    console.log('🚀 Spec-Driven Development Project Initializer\n');
+    // Get current working directory
+    const cwd = process.cwd();
+    // Prompt for project details
+    const answers = await promptInit();
+    // Resolve destination path
+    const destPath = path.resolve(cwd, answers.projectName);
+    // Check if destination exists
+    if (await fs.pathExists(destPath)) {
+        console.error(`\n❌ Error: Directory "${answers.projectName}" already exists.`);
+        console.error('   Please choose a different name or remove the existing directory.\n');
+        process.exit(1);
+    }
+    try {
+        // Copy template
+        console.log(`\n📦 Copying template to "${answers.projectName}"...`);
+        await copyTemplate(destPath);
+        // Create linear config if needed
+        if (answers.taskMode === 'linear') {
+            console.log('📋 Creating Linear sync configuration...');
+            await createLinearConfig(destPath);
+        }
+        // Initialize git if requested
+        if (answers.gitInit) {
+            console.log('🔧 Initializing git repository...');
+            initGit(destPath);
+        }
+        // Success message
+        console.log('\n✅ Project initialized successfully!\n');
+        console.log('Next steps:');
+        console.log(`  1. cd ${answers.projectName}`);
+        console.log('  2. Open the project in Cursor');
+        if (answers.taskMode === 'linear') {
+            console.log('  3. Configure Linear MCP in Cursor (see .cursor/MCP-SETUP.md if needed)');
+            console.log('  4. Run `/spec/init` to begin defining your project specification\n');
+        }
+        else {
+            console.log('  3. Run `/spec/init` to begin defining your project specification\n');
+        }
+    }
+    catch (error) {
+        console.error(`\n❌ Error: ${error instanceof Error ? error.message : String(error)}\n`);
+        process.exit(1);
+    }
+}
+//# sourceMappingURL=init.js.map

package/dist/commands/init.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"init.js","sourceRoot":"","sources":["../../src/commands/init.ts"],"names":[],"mappings":"AAAA,OAAO,IAAI,MAAM,MAAM,CAAC;AACxB,OAAO,EAAE,YAAY,EAAE,kBAAkB,EAAE,MAAM,yBAAyB,CAAC;AAC3E,OAAO,EAAE,OAAO,EAAE,MAAM,eAAe,CAAC;AACxC,OAAO,EAAE,UAAU,EAAE,MAAM,mBAAmB,CAAC;AAC/C,OAAO,EAAE,MAAM,UAAU,CAAC;AAE1B;;GAEG;AACH,MAAM,CAAC,KAAK,UAAU,OAAO;IAC3B,OAAO,CAAC,GAAG,CAAC,kDAAkD,CAAC,CAAC;IAEhE,gCAAgC;IAChC,MAAM,GAAG,GAAG,OAAO,CAAC,GAAG,EAAE,CAAC;IAE1B,6BAA6B;IAC7B,MAAM,OAAO,GAAG,MAAM,UAAU,EAAE,CAAC;IAEnC,2BAA2B;IAC3B,MAAM,QAAQ,GAAG,IAAI,CAAC,OAAO,CAAC,GAAG,EAAE,OAAO,CAAC,WAAW,CAAC,CAAC;IAExD,8BAA8B;IAC9B,IAAI,MAAM,EAAE,CAAC,UAAU,CAAC,QAAQ,CAAC,EAAE,CAAC;QAClC,OAAO,CAAC,KAAK,CAAC,yBAAyB,OAAO,CAAC,WAAW,mBAAmB,CAAC,CAAC;QAC/E,OAAO,CAAC,KAAK,CAAC,uEAAuE,CAAC,CAAC;QACvF,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;IAClB,CAAC;IAED,IAAI,CAAC;QACH,gBAAgB;QAChB,OAAO,CAAC,GAAG,CAAC,6BAA6B,OAAO,CAAC,WAAW,MAAM,CAAC,CAAC;QACpE,MAAM,YAAY,CAAC,QAAQ,CAAC,CAAC;QAE7B,iCAAiC;QACjC,IAAI,OAAO,CAAC,QAAQ,KAAK,QAAQ,EAAE,CAAC;YAClC,OAAO,CAAC,GAAG,CAAC,0CAA0C,CAAC,CAAC;YACxD,MAAM,kBAAkB,CAAC,QAAQ,CAAC,CAAC;QACrC,CAAC;QAED,8BAA8B;QAC9B,IAAI,OAAO,CAAC,OAAO,EAAE,CAAC;YACpB,OAAO,CAAC,GAAG,CAAC,mCAAmC,CAAC,CAAC;YACjD,OAAO,CAAC,QAAQ,CAAC,CAAC;QACpB,CAAC;QAED,kBAAkB;QAClB,OAAO,CAAC,GAAG,CAAC,yCAAyC,CAAC,CAAC;QACvD,OAAO,CAAC,GAAG,CAAC,aAAa,CAAC,CAAC;QAC3B,OAAO,CAAC,GAAG,CAAC,WAAW,OAAO,CAAC,WAAW,EAAE,CAAC,CAAC;QAC9C,OAAO,CAAC,GAAG,CAAC,iCAAiC,CAAC,CAAC;QAC/C,IAAI,OAAO,CAAC,QAAQ,KAAK,QAAQ,EAAE,CAAC;YAClC,OAAO,CAAC,GAAG,CAAC,0EAA0E,CAAC,CAAC;YACxF,OAAO,CAAC,GAAG,CAAC,sEAAsE,CAAC,CAAC;QACtF,CAAC;aAAM,CAAC;YACN,OAAO,CAAC,GAAG,CAAC,sEAAsE,CAAC,CAAC;QACtF,CAAC;IACH,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QACf,OAAO,CAAC,KAAK,CAAC,cAAc,KAAK,YAAY,KAAK,CAAC,CAAC,CAAC,KAAK,CAAC,OAAO,CAAC,CAAC,CAAC,MAAM,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;QACxF,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;IAClB,CAAC;AACH,CAAC"}

package/dist/index.d.ts

@@ -0,0 +1,3 @@
+#!/usr/bin/env node
+export {};
+//# sourceMappingURL=index.d.ts.map

package/dist/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":""}

package/dist/index.js

@@ -0,0 +1,16 @@
+#!/usr/bin/env node
+import { runInit } from './commands/init.js';
+const args = process.argv.slice(2);
+if (args.length === 0 || args[0] !== 'init') {
+    console.log('Spec-Driven Development CLI\n');
+    console.log('Usage:');
+    console.log('  spec init    Initialize a new SDD project\n');
+    process.exit(1);
+}
+if (args[0] === 'init') {
+    runInit().catch((error) => {
+        console.error('Fatal error:', error);
+        process.exit(1);
+    });
+}
+//# sourceMappingURL=index.js.map

package/dist/index.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":";AAEA,OAAO,EAAE,OAAO,EAAE,MAAM,oBAAoB,CAAC;AAE7C,MAAM,IAAI,GAAG,OAAO,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC;AAEnC,IAAI,IAAI,CAAC,MAAM,KAAK,CAAC,IAAI,IAAI,CAAC,CAAC,CAAC,KAAK,MAAM,EAAE,CAAC;IAC5C,OAAO,CAAC,GAAG,CAAC,+BAA+B,CAAC,CAAC;IAC7C,OAAO,CAAC,GAAG,CAAC,QAAQ,CAAC,CAAC;IACtB,OAAO,CAAC,GAAG,CAAC,+CAA+C,CAAC,CAAC;IAC7D,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;AAClB,CAAC;AAED,IAAI,IAAI,CAAC,CAAC,CAAC,KAAK,MAAM,EAAE,CAAC;IACvB,OAAO,EAAE,CAAC,KAAK,CAAC,CAAC,KAAK,EAAE,EAAE;QACxB,OAAO,CAAC,KAAK,CAAC,cAAc,EAAE,KAAK,CAAC,CAAC;QACrC,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;IAClB,CAAC,CAAC,CAAC;AACL,CAAC"}

package/dist/lib/copy-template.d.ts

@@ -0,0 +1,9 @@
+/**
+ * Copies the template directory to the destination
+ */
+export declare function copyTemplate(destPath: string): Promise<void>;
+/**
+ * Creates the linear sync config file if mode is linear
+ */
+export declare function createLinearConfig(projectPath: string): Promise<void>;
+//# sourceMappingURL=copy-template.d.ts.map

package/dist/lib/copy-template.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"copy-template.d.ts","sourceRoot":"","sources":["../../src/lib/copy-template.ts"],"names":[],"mappings":"AA+BA;;GAEG;AACH,wBAAsB,YAAY,CAAC,QAAQ,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC,CAclE;AAED;;GAEG;AACH,wBAAsB,kBAAkB,CAAC,WAAW,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC,CAM3E"}

package/dist/lib/copy-template.js

@@ -0,0 +1,51 @@
+import fs from 'fs-extra';
+import path from 'path';
+import { fileURLToPath } from 'url';
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+/**
+ * Gets the template directory path
+ * Works in both development (template at repo root) and published (template at package root)
+ */
+async function getTemplateDir() {
+    // Try package root first (for published package)
+    const packageRoot = path.resolve(__dirname, '../..');
+    const templateInPackage = path.join(packageRoot, 'template');
+    // Try repo root (for development)
+    const repoRoot = path.resolve(__dirname, '../../../..');
+    const templateInRepo = path.join(repoRoot, 'template');
+    // Return the first path that exists
+    if (await fs.pathExists(templateInPackage)) {
+        return templateInPackage;
+    }
+    if (await fs.pathExists(templateInRepo)) {
+        return templateInRepo;
+    }
+    // Fallback to package root (will fail with clear error in copyTemplate)
+    return templateInPackage;
+}
+/**
+ * Copies the template directory to the destination
+ */
+export async function copyTemplate(destPath) {
+    const templateDir = await getTemplateDir();
+    if (!(await fs.pathExists(templateDir))) {
+        throw new Error(`Template directory not found: ${templateDir}`);
+    }
+    // Check if destination exists
+    if (await fs.pathExists(destPath)) {
+        throw new Error(`Destination already exists: ${destPath}`);
+    }
+    // Copy template to destination
+    await fs.copy(templateDir, destPath);
+}
+/**
+ * Creates the linear sync config file if mode is linear
+ */
+export async function createLinearConfig(projectPath) {
+    const linearDir = path.join(projectPath, 'work', 'linear');
+    const configPath = path.join(linearDir, 'sync-config.md');
+    await fs.ensureDir(linearDir);
+    await fs.writeFile(configPath, 'MODE=linear\n', 'utf-8');
+}
+//# sourceMappingURL=copy-template.js.map

package/dist/lib/copy-template.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"copy-template.js","sourceRoot":"","sources":["../../src/lib/copy-template.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,MAAM,UAAU,CAAC;AAC1B,OAAO,IAAI,MAAM,MAAM,CAAC;AACxB,OAAO,EAAE,aAAa,EAAE,MAAM,KAAK,CAAC;AAEpC,MAAM,UAAU,GAAG,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;AAClD,MAAM,SAAS,GAAG,IAAI,CAAC,OAAO,CAAC,UAAU,CAAC,CAAC;AAE3C;;;GAGG;AACH,KAAK,UAAU,cAAc;IAC3B,iDAAiD;IACjD,MAAM,WAAW,GAAG,IAAI,CAAC,OAAO,CAAC,SAAS,EAAE,OAAO,CAAC,CAAC;IACrD,MAAM,iBAAiB,GAAG,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,UAAU,CAAC,CAAC;IAE7D,kCAAkC;IAClC,MAAM,QAAQ,GAAG,IAAI,CAAC,OAAO,CAAC,SAAS,EAAE,aAAa,CAAC,CAAC;IACxD,MAAM,cAAc,GAAG,IAAI,CAAC,IAAI,CAAC,QAAQ,EAAE,UAAU,CAAC,CAAC;IAEvD,oCAAoC;IACpC,IAAI,MAAM,EAAE,CAAC,UAAU,CAAC,iBAAiB,CAAC,EAAE,CAAC;QAC3C,OAAO,iBAAiB,CAAC;IAC3B,CAAC;IACD,IAAI,MAAM,EAAE,CAAC,UAAU,CAAC,cAAc,CAAC,EAAE,CAAC;QACxC,OAAO,cAAc,CAAC;IACxB,CAAC;IACD,wEAAwE;IACxE,OAAO,iBAAiB,CAAC;AAC3B,CAAC;AAED;;GAEG;AACH,MAAM,CAAC,KAAK,UAAU,YAAY,CAAC,QAAgB;IACjD,MAAM,WAAW,GAAG,MAAM,cAAc,EAAE,CAAC;IAE3C,IAAI,CAAC,CAAC,MAAM,EAAE,CAAC,UAAU,CAAC,WAAW,CAAC,CAAC,EAAE,CAAC;QACxC,MAAM,IAAI,KAAK,CAAC,iCAAiC,WAAW,EAAE,CAAC,CAAC;IAClE,CAAC;IAED,8BAA8B;IAC9B,IAAI,MAAM,EAAE,CAAC,UAAU,CAAC,QAAQ,CAAC,EAAE,CAAC;QAClC,MAAM,IAAI,KAAK,CAAC,+BAA+B,QAAQ,EAAE,CAAC,CAAC;IAC7D,CAAC;IAED,+BAA+B;IAC/B,MAAM,EAAE,CAAC,IAAI,CAAC,WAAW,EAAE,QAAQ,CAAC,CAAC;AACvC,CAAC;AAED;;GAEG;AACH,MAAM,CAAC,KAAK,UAAU,kBAAkB,CAAC,WAAmB;IAC1D,MAAM,SAAS,GAAG,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,MAAM,EAAE,QAAQ,CAAC,CAAC;IAC3D,MAAM,UAAU,GAAG,IAAI,CAAC,IAAI,CAAC,SAAS,EAAE,gBAAgB,CAAC,CAAC;IAE1D,MAAM,EAAE,CAAC,SAAS,CAAC,SAAS,CAAC,CAAC;IAC9B,MAAM,EAAE,CAAC,SAAS,CAAC,UAAU,EAAE,eAAe,EAAE,OAAO,CAAC,CAAC;AAC3D,CAAC"}

package/dist/lib/git.d.ts

@@ -0,0 +1,5 @@
+/**
+ * Initializes a git repository in the specified directory
+ */
+export declare function initGit(projectPath: string): void;
+//# sourceMappingURL=git.d.ts.map

package/dist/lib/git.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"git.d.ts","sourceRoot":"","sources":["../../src/lib/git.ts"],"names":[],"mappings":"AAGA;;GAEG;AACH,wBAAgB,OAAO,CAAC,WAAW,EAAE,MAAM,GAAG,IAAI,CASjD"}

package/dist/lib/git.js

@@ -0,0 +1,16 @@
+import { execSync } from 'child_process';
+/**
+ * Initializes a git repository in the specified directory
+ */
+export function initGit(projectPath) {
+    try {
+        execSync('git init', {
+            cwd: projectPath,
+            stdio: 'inherit',
+        });
+    }
+    catch (error) {
+        throw new Error(`Failed to initialize git repository: ${error}`);
+    }
+}
+//# sourceMappingURL=git.js.map

package/dist/lib/git.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"git.js","sourceRoot":"","sources":["../../src/lib/git.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,QAAQ,EAAE,MAAM,eAAe,CAAC;AAGzC;;GAEG;AACH,MAAM,UAAU,OAAO,CAAC,WAAmB;IACzC,IAAI,CAAC;QACH,QAAQ,CAAC,UAAU,EAAE;YACnB,GAAG,EAAE,WAAW;YAChB,KAAK,EAAE,SAAS;SACjB,CAAC,CAAC;IACL,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QACf,MAAM,IAAI,KAAK,CAAC,wCAAwC,KAAK,EAAE,CAAC,CAAC;IACnE,CAAC;AACH,CAAC"}

package/dist/lib/prompts.d.ts

@@ -0,0 +1,10 @@
+export interface InitAnswers {
+    projectName: string;
+    taskMode: 'local' | 'linear';
+    gitInit: boolean;
+}
+/**
+ * Prompts the user for project initialization options
+ */
+export declare function promptInit(): Promise<InitAnswers>;
+//# sourceMappingURL=prompts.d.ts.map

package/dist/lib/prompts.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"prompts.d.ts","sourceRoot":"","sources":["../../src/lib/prompts.ts"],"names":[],"mappings":"AAEA,MAAM,WAAW,WAAW;IAC1B,WAAW,EAAE,MAAM,CAAC;IACpB,QAAQ,EAAE,OAAO,GAAG,QAAQ,CAAC;IAC7B,OAAO,EAAE,OAAO,CAAC;CAClB;AAED;;GAEG;AACH,wBAAsB,UAAU,IAAI,OAAO,CAAC,WAAW,CAAC,CAoCvD"}

package/dist/lib/prompts.js

@@ -0,0 +1,41 @@
+import inquirer from 'inquirer';
+/**
+ * Prompts the user for project initialization options
+ */
+export async function promptInit() {
+    const answers = await inquirer.prompt([
+        {
+            type: 'input',
+            name: 'projectName',
+            message: 'Project name (folder name):',
+            validate: (input) => {
+                if (!input.trim()) {
+                    return 'Project name cannot be empty';
+                }
+                // Basic validation for folder names
+                if (/[<>:"/\\|?*]/.test(input)) {
+                    return 'Project name contains invalid characters';
+                }
+                return true;
+            },
+        },
+        {
+            type: 'list',
+            name: 'taskMode',
+            message: 'Task mode:',
+            choices: [
+                { name: 'local', value: 'local' },
+                { name: 'linear', value: 'linear' },
+            ],
+            default: 'local',
+        },
+        {
+            type: 'confirm',
+            name: 'gitInit',
+            message: 'Initialize git repository?',
+            default: true,
+        },
+    ]);
+    return answers;
+}
+//# sourceMappingURL=prompts.js.map

package/dist/lib/prompts.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"prompts.js","sourceRoot":"","sources":["../../src/lib/prompts.ts"],"names":[],"mappings":"AAAA,OAAO,QAAQ,MAAM,UAAU,CAAC;AAQhC;;GAEG;AACH,MAAM,CAAC,KAAK,UAAU,UAAU;IAC9B,MAAM,OAAO,GAAG,MAAM,QAAQ,CAAC,MAAM,CAAc;QACjD;YACE,IAAI,EAAE,OAAO;YACb,IAAI,EAAE,aAAa;YACnB,OAAO,EAAE,6BAA6B;YACtC,QAAQ,EAAE,CAAC,KAAa,EAAE,EAAE;gBAC1B,IAAI,CAAC,KAAK,CAAC,IAAI,EAAE,EAAE,CAAC;oBAClB,OAAO,8BAA8B,CAAC;gBACxC,CAAC;gBACD,oCAAoC;gBACpC,IAAI,cAAc,CAAC,IAAI,CAAC,KAAK,CAAC,EAAE,CAAC;oBAC/B,OAAO,0CAA0C,CAAC;gBACpD,CAAC;gBACD,OAAO,IAAI,CAAC;YACd,CAAC;SACF;QACD;YACE,IAAI,EAAE,MAAM;YACZ,IAAI,EAAE,UAAU;YAChB,OAAO,EAAE,YAAY;YACrB,OAAO,EAAE;gBACP,EAAE,IAAI,EAAE,OAAO,EAAE,KAAK,EAAE,OAAO,EAAE;gBACjC,EAAE,IAAI,EAAE,QAAQ,EAAE,KAAK,EAAE,QAAQ,EAAE;aACpC;YACD,OAAO,EAAE,OAAO;SACjB;QACD;YACE,IAAI,EAAE,SAAS;YACf,IAAI,EAAE,SAAS;YACf,OAAO,EAAE,4BAA4B;YACrC,OAAO,EAAE,IAAI;SACd;KACF,CAAC,CAAC;IAEH,OAAO,OAAO,CAAC;AACjB,CAAC"}

package/package.json

@@ -0,0 +1,30 @@
+{
+  "name": "@eskoubar95/spec",
+  "version": "0.1.0",
+  "private": false,
+  "bin": {
+    "spec": "dist/index.js"
+  },
+  "type": "module",
+  "main": "dist/index.js",
+  "files": [
+    "dist",
+    "template"
+  ],
+  "scripts": {
+    "build": "tsc",
+    "dev": "tsc --watch",
+    "start": "node dist/index.js",
+    "prepublishOnly": "cp -r ../template . || true"
+  },
+  "dependencies": {
+    "inquirer": "^9.2.0",
+    "fs-extra": "^11.2.0"
+  },
+  "devDependencies": {
+    "@types/fs-extra": "^11.0.4",
+    "@types/inquirer": "^9.0.7",
+    "@types/node": "^20.11.0",
+    "typescript": "^5.3.3"
+  }
+}

package/template/.cursor/MCP-SETUP.md

@@ -0,0 +1,34 @@
+# Linear MCP Setup (Optional)
+
+If you're using Linear task mode, you may want to configure the Linear MCP server in Cursor to enable Linear integration.
+
+## Quick Setup
+
+1. Get your Linear API key from https://linear.app/settings/api
+2. Configure MCP in Cursor Settings → Features → Model Context Protocol
+3. Add Linear MCP server configuration with your API key
+4. Restart Cursor
+
+## Settings File Location
+
+- **macOS**: `~/Library/Application Support/Cursor/User/globalStorage/rooveterinaryinc.roo-cline/settings/cline_mcp_settings.json`
+- **Windows**: `%APPDATA%\Cursor\User\globalStorage\rooveterinaryinc.roo-cline\settings\cline_mcp_settings.json`
+- **Linux**: `~/.config/Cursor/User/globalStorage/rooveterinaryinc.roo-cline/settings/cline_mcp_settings.json`
+
+## Example Configuration
+
+```json
+{
+  "mcpServers": {
+    "linear": {
+      "command": "npx",
+      "args": ["-y", "@modelcontextprotocol/server-linear"],
+      "env": {
+        "LINEAR_API_KEY": "your-api-key-here"
+      }
+    }
+  }
+}
+```
+
+For more details, see [MCP Documentation](https://modelcontextprotocol.io).

package/template/.cursor/commands/spec/init.md

@@ -0,0 +1,51 @@
+You are initiating a new project using Spec-Driven Development (SDD).
+
+MODE: Research / Ideation
+GOAL: Turn an unstructured idea into a clear, high-level root specification.
+
+Step 1 — Prompt the user
+Ask the user to pitch the idea freely in their own words.
+Explicitly state that the idea can be incomplete, messy, or uncertain.
+
+Step 2 — While listening, do NOT assume
+While processing the pitch:
+- Identify the core problem being addressed
+- Identify the intended users or stakeholders
+- Identify the primary value proposition
+
+Constraints:
+- Stay strictly high-level
+- Do NOT introduce technical solutions, stacks, frameworks, or architecture
+- Do NOT expand into execution, tasks, or implementation
+- If information is missing, mark it as uncertainty instead of guessing
+
+Step 3 — Clarify only what truly matters
+After the pitch:
+- Ask a small number of high-impact clarifying questions
+- Prioritize questions that affect scope, value, or feasibility
+- Avoid exhaustive checklists or domain deep dives
+
+Step 4 — Write the initial specification
+Create or update the following files:
+- `spec/00-root-spec.md`
+- `spec/03-risks.md`
+- `spec/04-open-questions.md`
+
+Populate them as follows:
+- Root spec: concise summary of the idea, problem, users, value, and tentative scope
+- Risks: only risks that are already visible at this early stage
+- Open questions: unresolved assumptions or decisions that require input
+
+Rules:
+- Keep all content lightweight and editable
+- Do not create additional spec files
+- Do not escalate to design or planning modes
+
+Step 5 — Report back
+Briefly explain:
+- What was captured
+- What remains unclear
+- What the natural next step would be (without executing it)
+
+PRINCIPLE:
+Clarity over completeness. Direction over detail.

package/template/.cursor/commands/spec/plan.md

@@ -0,0 +1,61 @@
+You are moving the project from “Research / Ideation” into “Planning”.
+
+MODE: Planning
+GOAL: Turn the current specification into an executable plan (milestones + tasks) while keeping the spec consistent.
+
+Inputs (source of truth):
+- `spec/00-root-spec.md`
+- `spec/03-risks.md`
+- `spec/04-open-questions.md`
+
+Before you plan
+1) Read the source-of-truth files above.
+2) If there are critical unknowns that block planning, ask only the minimum clarifying questions.
+   - If unknowns exist but planning can still proceed, capture them as assumptions and keep them in `spec/04-open-questions.md`.
+
+Planning outputs
+A) Spec artifacts (create only if needed by planning)
+- Create or update `spec/01-prd.md` if the feature set needs to be made explicit.
+- Create or update `spec/06-acceptance.md` with high-level acceptance criteria / definition of done.
+
+Rules for spec artifacts:
+- Stay high-level. Do not write deep architecture.
+- Do not introduce new features that were not implied by the root spec.
+- If you suggest a new requirement, mark it as a question or assumption.
+
+B) Execution artifacts (always produce these)
+Create or update:
+- `work/backlog/milestones.md`
+- `work/backlog/tasks.local.md`
+
+Milestones requirements:
+- 3–7 milestones max.
+- Each milestone has: objective, scope (in/out), and exit criteria.
+
+Tasks requirements:
+- Tasks must be traceable to the spec.
+- Each task has: description, acceptance signal, dependencies, and rough estimate (S/M/L).
+- Keep tasks implementation-agnostic unless necessary.
+
+C) Risk-driven planning
+- Update `spec/03-risks.md` with any planning-discovered risks.
+- For the top 3 risks, add a concrete mitigation task into `tasks.local.md`.
+
+D) Optional: Linear integration (ONLY if configured)
+- Check if `work/linear/sync-config.md` exists.
+  - If it exists and declares `MODE=linear`, then in addition to local files:
+    - Propose a Linear structure (Project + Epics + Issues) that mirrors the milestones.
+    - Ask for confirmation before creating/updating anything in Linear.
+  - If it does not exist or is not set to linear: keep everything local.
+
+Step-by-step deliverable
+1) A short “Planning Summary” in chat: what you planned and what remains uncertain.
+2) Updated/created files listed above.
+3) A recommended next step:
+   - either `/task/start` for the first task
+   - or `/spec/refine` if the spec is still too unclear
+
+PRINCIPLES:
+- Planning is not implementation.
+- Clarity and traceability over excessive detail.
+- Keep it professional, lightweight, and actionable.

package/template/.cursor/commands/spec/refine.md

@@ -0,0 +1,70 @@
+We are refining an existing project specification.
+
+Use `spec/root-spec.md` as the source of truth.
+
+During refinement:
+- Improve clarity and structure.
+- Add detail only where it clearly adds value.
+- Surface new questions instead of making assumptions.
+- If new risks appear, add them explicitly.
+
+Do not introduce heavy technical detail unless it naturally emerges.
+
+Update the spec incrementally and explain what changed.
+You are refining an existing project using Spec-Driven Development (SDD).
+
+MODE: Refinement
+GOAL: Improve clarity, consistency, and decision-readiness of the specification without escalating into planning or implementation.
+
+Source of truth:
+- `spec/00-root-spec.md`
+- `spec/03-risks.md`
+- `spec/04-open-questions.md`
+
+Before refining:
+1) Read all source-of-truth files.
+2) Identify ambiguities, contradictions, or weakly defined areas.
+3) Do NOT assume missing information.
+
+Refinement rules:
+- Stay at specification level.
+- Do NOT create tasks, milestones, or implementation plans.
+- Do NOT introduce architecture, frameworks, or tooling unless it is already implied and unavoidable.
+- Prefer sharpening language over adding volume.
+
+Allowed refinement actions:
+A) Root spec
+- Clarify problem statement, users, and value proposition.
+- Tighten scope boundaries (in-scope / out-of-scope).
+- Make implicit assumptions explicit.
+
+B) Open questions
+- Add newly discovered uncertainties.
+- Rephrase vague questions into concrete, answerable ones.
+- Remove questions that are now resolved.
+
+C) Risks
+- Add newly surfaced risks.
+- Refine existing risks with clearer impact or likelihood.
+- Do NOT add mitigation tasks here.
+
+D) Decisions (only if unavoidable)
+- If a decision has clearly been made during refinement, append it to:
+  `spec/05-decisions.md`
+- Keep decisions lightweight (what was decided, why, and consequences).
+
+File creation rules:
+- Only create `spec/05-decisions.md` if an explicit decision is identified.
+- Do NOT create PRD, architecture, acceptance, or planning files.
+
+After refinement:
+1) Update the relevant spec files.
+2) In chat, provide a short summary:
+   - What improved
+   - What remains unclear
+   - Whether the project is ready for planning (`/spec/plan`) or needs more refinement
+
+PRINCIPLES:
+- Refinement is about precision, not expansion.
+- Reduce ambiguity before increasing structure.
+- Specs should become easier to reason about after each refinement.

package/template/.cursor/commands/task/start.md

@@ -0,0 +1,64 @@
+You are starting work on a single task using Spec-Driven Development (SDD).
+
+MODE: Execution / Engineer Mode
+GOAL: Safely begin implementation of one task with clear scope, correctness, and discipline.
+
+Inputs (source of truth):
+- `spec/00-root-spec.md`
+- `spec/06-acceptance.md` (if it exists)
+- `work/backlog/tasks.local.md`
+
+Step 1 — Select the task
+Ask the user which task they want to start.
+The task must exist in `tasks.local.md` or be explicitly confirmed as new.
+
+If the task is new:
+- Ask why it exists
+- Ensure it aligns with the current spec
+- Add it to `tasks.local.md` before proceeding
+
+Step 2 — Establish task boundaries
+For the selected task:
+- Restate the task objective in your own words
+- Identify what is explicitly IN scope
+- Identify what is explicitly OUT of scope
+- Identify dependencies or prerequisites
+
+If scope is unclear, pause and ask clarifying questions.
+Do NOT guess.
+
+Step 3 — Acceptance and correctness
+Determine how completion will be validated:
+- Reference acceptance criteria if they exist
+- Otherwise, define a minimal acceptance signal (what proves this task is done)
+
+Do not proceed without a clear acceptance signal.
+
+Step 4 — Engineering setup
+Before implementation, ensure:
+- A dedicated branch should be created (suggest a branch name)
+- The user understands what files or areas are likely to be touched
+- Tests may be required (unit, integration, or manual), if applicable
+
+Do NOT write code yet.
+
+Step 5 — Implementation plan (lightweight)
+Produce a short, ordered list of implementation steps.
+Keep it minimal and focused on this task only.
+Avoid over-design or premature refactoring.
+
+Step 6 — Safety checks
+Before execution, confirm:
+- The task aligns with the spec
+- Risks are understood (add to `spec/03-risks.md` if a new risk is discovered)
+- The plan does not introduce unintended scope creep
+
+Step 7 — Handoff
+End by asking for explicit confirmation to proceed with implementation.
+Do not begin coding until confirmation is given.
+
+PRINCIPLES:
+- One task at a time
+- No hidden scope
+- Correctness over speed
+- Discipline beats improvisation

package/template/.cursor/commands/task/validate.md

@@ -0,0 +1,64 @@
+You are validating the completion of a single task using Spec-Driven Development (SDD).
+
+MODE: Validation / Quality Gate
+GOAL: Ensure the task is correct, complete, and safe to integrate before commit or PR.
+
+Inputs (source of truth):
+- `spec/00-root-spec.md`
+- `spec/06-acceptance.md` (if it exists)
+- `spec/03-risks.md`
+- `work/backlog/tasks.local.md`
+
+Step 1 — Identify the task
+Ask which task is being validated.
+Confirm that the task exists in `tasks.local.md` and is currently in progress.
+
+Step 2 — Restate intent
+Restate:
+- What this task was supposed to achieve
+- What success looks like (acceptance signal)
+
+If intent or acceptance is unclear, stop and surface the issue.
+
+Step 3 — Validation checklist (lightweight)
+Evaluate the task against these dimensions:
+- Correctness: Does it meet the acceptance signal?
+- Scope: Was anything implemented outside the defined scope?
+- Spec alignment: Is the spec still accurate?
+- Risk impact: Did this task introduce new risks or reduce existing ones?
+
+Do not invent requirements.
+
+Step 4 — Testing and evidence
+Ask what evidence exists:
+- Automated tests
+- Manual verification steps
+- Screenshots, logs, or other proof
+
+If testing is missing but appropriate, flag it explicitly.
+Do not write tests unless asked.
+
+Step 5 — Documentation and traceability
+Ensure:
+- Any relevant documentation is updated (spec or README if applicable)
+- Decisions made during implementation are captured in `spec/05-decisions.md` (only if real decisions occurred)
+
+Step 6 — Release readiness
+Assess whether the task is:
+- Safe to commit
+- Ready for PR
+- Requires follow-up work
+
+If follow-up is required:
+- Propose new tasks and add them to `tasks.local.md`
+
+Step 7 — Close or loop
+Conclude with one of the following outcomes:
+- Approved for commit / PR
+- Requires fixes (clearly listed)
+- Requires spec refinement (`/spec/refine`)
+
+PRINCIPLES:
+- Validation is about confidence, not perfection
+- Evidence beats assumptions
+- Do not silently pass incomplete work

package/template/.cursor/rules/00-pos.mdc

@@ -0,0 +1,48 @@
+---
+alwaysApply: true
+---
+
+# Project Operating System (POS)
+
+You are operating inside a Project Operating System designed for professional, spec-driven software development.
+
+## Core principles
+- The specification is the source of truth.
+- Work progresses through explicit phases (spec → plan → task → validate).
+- Do not assume missing information.
+- Prefer clarity and correctness over speed.
+- Avoid unnecessary complexity and premature decisions.
+
+## Modes of operation
+You must respect the current mode implied by the active command:
+- Spec mode (`/spec/*`): understanding, clarification, and alignment only.
+- Task mode (`/task/*`): focused execution and validation of a single task.
+
+Never mix modes.
+Do not introduce execution concerns during spec mode.
+Do not introduce new requirements during task mode.
+
+## Spec discipline
+- The `spec/` directory is the authoritative source of project intent.
+- If work reveals ambiguity, update `spec/04-open-questions.md`.
+- If work reveals risk, update `spec/03-risks.md`.
+- If a real decision is made, record it in `spec/05-decisions.md`.
+
+## Scope control
+- One task at a time.
+- No hidden scope expansion.
+- Anything out of scope must be explicitly called out.
+
+## Quality expectations
+- All work must be verifiable.
+- Acceptance signals define completion.
+- Evidence is required before approval (tests, checks, or clear validation steps).
+
+## Agent behavior
+- Ask concise, high-impact questions when clarity is missing.
+- Stop and ask before guessing.
+- Explain reasoning briefly when making changes to files.
+- Do not perform actions outside the current command’s responsibility.
+
+## Goal
+Help the user work at an engineer level by enforcing structure, discipline, and traceability — without unnecessary overhead.

package/template/.cursor/rules/01-sdd.mdc

@@ -0,0 +1,61 @@
+---
+alwaysApply: true
+---
+
+# Spec-Driven Development (SDD)
+
+This project follows Spec-Driven Development.
+Specifications are living artifacts that drive planning, execution, and validation.
+
+## Core SDD rules
+- The specification defines intent; code implements intent.
+- Specs evolve continuously throughout the project lifecycle.
+- No work may proceed on assumptions that are not reflected in the spec.
+
+## Spec lifecycle
+SDD operates through explicit transitions:
+- Idea → Specification (`/spec/init`)
+- Specification → Clarity (`/spec/refine`)
+- Specification → Plan (`/spec/plan`)
+- Plan → Execution (`/task/start`)
+- Execution → Confidence (`/task/validate`)
+
+Each transition must leave the specification more precise than before.
+
+## What the spec must capture
+The spec must always make explicit:
+- What problem is being solved
+- Who it is for
+- What is in scope and out of scope
+- What success means
+
+If any of these are unclear, they must be surfaced as open questions.
+
+## Handling change
+Change is expected.
+When change occurs:
+- Update the spec before updating code
+- Re-evaluate risks and assumptions
+- Ensure tasks remain traceable to spec intent
+
+Never allow the spec and implementation to diverge silently.
+
+## Decisions
+- Decisions are explicit moments of commitment
+- Only record real decisions (not ideas or suggestions)
+- Decisions must explain: what was decided, why, and consequences
+
+## Anti-patterns (strictly avoid)
+- Writing code to discover requirements
+- Planning before understanding
+- Expanding scope during task execution
+- Treating specs as documentation-only artifacts
+
+## Agent responsibility
+- Treat the spec as the authoritative truth
+- Prefer updating the spec over guessing
+- Stop and ask when intent is ambiguous
+- Keep specs concise, readable, and actionable
+
+## Goal
+Enable disciplined, professional development by making intent explicit before implementation.

package/template/.cursor/rules/02-work-mode.mdc

@@ -0,0 +1,65 @@
+---
+alwaysApply: true
+---
+
+# Work Mode (Execution Discipline)
+
+This rule governs how work is executed once planning has occurred.
+It ensures tasks are handled with engineering discipline, traceability, and quality control.
+
+## Purpose
+Work Mode exists to:
+- Prevent ad-hoc implementation
+- Enforce task focus and scope control
+- Ensure validation before integration
+
+## Entry conditions
+Work Mode is active whenever a `/task/*` command is used.
+
+Before any implementation work:
+- A task must be explicitly selected or confirmed
+- The task must align with the current specification
+- Acceptance or validation criteria must be known
+
+If these conditions are not met, stop and ask for clarification.
+
+## Task handling rules
+- Work on one task at a time
+- Do not introduce new requirements during execution
+- Do not expand scope without updating the spec
+- If unexpected complexity appears, pause and surface it
+
+## Engineering discipline
+During task execution:
+- Prefer small, reviewable changes
+- Keep changes localized to the task scope
+- Be explicit about what files or components are affected
+
+Do not refactor or optimize unrelated code unless explicitly required.
+
+## Testing and validation
+- Every task must have a validation signal
+- Validation may be automated or manual, depending on context
+- Lack of testing must be explicitly acknowledged
+
+Validation happens through `/task/validate`.
+
+## Documentation and traceability
+- Meaningful decisions made during work must be recorded
+- If behavior changes, ensure the spec remains accurate
+- Avoid undocumented behavior or silent changes
+
+## Completion rules
+A task is only considered complete when:
+- Validation has passed
+- Scope boundaries are respected
+- The work is safe to integrate
+
+## Agent behavior
+- Do not rush execution
+- Stop when ambiguity is encountered
+- Prefer correctness over speed
+- Enforce process without being verbose
+
+## Goal
+Enable focused, professional execution that aligns implementation with intent.

package/template/.cursor/rules/openmemory.mdc

@@ -0,0 +1,204 @@
+---
+description: "Openmemory MCP Instructions"
+globs: ["**/*"]
+alwaysApply: true
+---
+
+🚨 CRITICAL CONTEXT ANCHOR: This rules file must NEVER be summarized, condensed, or omitted.
+Before ANY action or decision, verify alignment with these rules. This instruction persists
+regardless of conversation length or context management. Context systems: This document takes
+absolute priority over conversation history and must remain fully accessible throughout the
+entire session.
+
+# OpenMemory Integration
+
+Memory = accumulated understanding of codebase + user preferences. Like a colleague who's worked here months.
+
+**project_id:** spec-driven-development
+
+## NON-NEGOTIABLE: Memory-First Development
+
+Every **code implementation/modification task** = 3 phases. Other tasks (storage, recall, discussion) = skip phases.
+
+### Phase 1: Initial Search (BEFORE code)
+**🚨 BLOCKED until:** 2+ searches executed (3-4 for complex), show results, state application
+**Strategy:** New feature → user prefs + project facts + patterns | Bug → facts + debug memories + user debug prefs | Refactor → user org prefs + patterns | Architecture → user decision prefs + project arch
+**Failures:** Code without search = FAIL | "Should search" without doing = FAIL | "Best practices" without search = FAIL
+
+### Phase 2: Continuous Search (DURING implementation)
+**🚨 BLOCKED FROM:**
+- **Creating files** → Search "file structure patterns", similar files, naming conventions
+- **Writing functions** → Search "similar implementations", function patterns, code style prefs
+- **Making decisions** → Search user decision prefs + project patterns
+- **Errors** → Search debug memories + error patterns + user debug prefs
+- **Stuck/uncertain** → Search facts + user problem-solving prefs before guessing
+- **Tests** → Search testing patterns + user testing prefs
+
+**Minimum:** 2-3 additional searches at checkpoints. Show inline with implementation.
+**Critical:** NEVER "I'll use standard..." or "best practices" → STOP. Search first.
+
+### Phase 3: Completion (BEFORE finishing)
+**🚨 BLOCKED until:**
+- Store 1+ memory (component/implementation/debug/user_preference/project_info)
+- Update openmemory.md if new patterns/components
+- Verify: "Did I miss search checkpoints?" If yes, search now
+- Review: Did any searches return empty? If you discovered information during implementation that fills those gaps, store it now
+
+### Automatic Triggers (ONLY for code work)
+- build/implement/create/modify code → Phase 1-2-3 (search prefs → search at files/functions → store)
+- fix bug/debug (requiring code changes) → Phase 1-2-3 (search debug → search at steps → store fix)
+- refactor code → Phase 1-2-3 (search org prefs → search before changes → store patterns)
+- **SKIP phases:** User providing info ("Remember...", "Store...") → direct add-memory | Simple recall questions → direct search
+- Stuck during implementation → Search immediately | Complete work → Phase 3
+
+## CRITICAL: Empty Guide Check
+**FIRST ACTION:** Check openmemory.md empty? If yes → Deep Dive (Phase 1 → analyze → document → Phase 3)
+
+## 3 Search Patterns
+1. `user_preference=true` only → Global user preferences
+2. `user_preference=true` + `project_id` → Project-specific user preferences
+3. `project_id` only → Project facts
+
+**Quick Ref:** Not about you? → project_id | Your prefs THIS project? → both | Your prefs ALL projects? → user_preference=true
+
+## When to Search User Preferences
+**Part of Phase 1 + 2.** Tasks involving HOW = pref searches required.
+
+**ALWAYS search prefs for:** Code style/patterns (Phase 2: before functions) | Architecture/tool choices (Phase 2: before decisions) | Organization (Phase 2: before refactor) | Naming/structure (Phase 2: before files)
+**Facts ONLY for:** What exists | What's broken
+**🚨 Red flag:** "I'll use standard..." → Phase 2 BLOCKER. Search prefs first.
+
+**Task-specific queries (be specific):**
+- Feature → "clarification prefs", "implementation approach prefs"
+- Debug → "debug workflow prefs", "error investigation prefs", "problem-solving approach"
+- Code → "code style prefs", "review prefs", "testing prefs"
+- Arch → "decision-making prefs", "arch prefs", "design pattern prefs"
+
+## Query Intelligence
+**Transform comprehensively:** "auth" → "authentication system architecture and implementation" | Include context | Expand acronyms
+**Disambiguate first:** "design" → UI/UX design vs. software architecture design vs. code formatting/style | "structure" → file organization vs. code architecture vs. data structure | "style" → visual styling vs. code formatting | "organization" → file/folder layout vs. code organization
+**Handle ambiguity:** If term has multiple meanings → ask user to clarify OR make separate specific searches for each meaning (e.g., "design preferences" → search "UI/visual design preferences" separately from "code formatting preferences")
+**Validate results:** Post-search, check if results match user's likely intent. Off-topic results (e.g., "code indentation" when user meant "visual design")? → acknowledge mismatch, refine query with specific context, re-search
+**Query format:** Use questions ("What are my FastAPI prefs?") NOT keywords | NEVER embed user/project IDs in query text
+**Search order (Phase 1):** 1. Global user prefs (user_preference=true) 2. Project facts (project_id) 3. Project prefs (both)
+
+## Memory Collection (Phase 3)
+**Save:** Arch decisions, problem-solving, implementation strategies, component relationships
+**Skip:** Trivial fixes
+**Learning from corrections (store as prefs):** Indentation = formatting pref | Rename = naming convention | Restructure = arch pref | Commit reword = git workflow
+**Auto-store:** 3+ files/components OR multi-step flows OR non-obvious behavior OR complete work
+
+## Memory Types
+**🚨 SECURITY:** Scan for secrets before storing. If found, DO NOT STORE.
+- **Component:** Title "[Component] - [Function]"; Content: Location, Purpose, Services, I/O
+- **Implementation:** Title "[Action] [Feature]"; Content: Purpose, Steps, Key decisions
+- **Debug:** Title "Fix: [Issue]"; Content: Issue, Diagnosis, Solution
+- **User Preference:** Title "[Scope] [Type]"; Content: Actionable preference
+- **Project Info:** Title "[Area] [Config]"; Content: General knowledge
+
+**Project Facts (project_id ONLY):** Component, Implementation, Debug, Project Info
+**User Preferences (user_preference=true):** User Preference (global → user_preference=true ONLY | project-specific → user_preference=true + project_id)
+
+## 🚨 CRITICAL: Storage Intelligence
+
+**RULE: Only ONE of these three patterns:**
+
+| Pattern | user_preference | project_id | When to Use | Memory Types |
+|---------|-----------------|------------|-------------|--------------|
+| **Project Facts** | ❌ OMIT (false) | ✅ INCLUDE | Objective info about THIS project | component, implementation, project_info, debug |
+| **Project Prefs** | ✅ true | ✅ INCLUDE | YOUR preferences in THIS project | user_preference (project-specific) |
+| **Global Prefs** | ✅ true | ❌ OMIT | YOUR preferences across ALL projects | user_preference (global) |
+
+**Before EVERY add-memory:**
+1. ❓ Code/architecture/facts? → project_id ONLY | ❓ MY pref for ALL projects? → user_preference=true ONLY | ❓ MY pref for THIS project? → BOTH
+2. ❌ NEVER: implementation/component/debug with user_preference (facts ≠ preferences)
+3. ✅ ALWAYS: Review table above to validate pattern
+
+## Tool Usage
+**search-memory:** Required: query | Optional: user_preference, project_id, memory_types[], namespaces[]
+
+**add-memory:** Required: title, content, metadata{} | Optional: user_preference, project_id
+- **🚨 BEFORE calling:** Review Storage Intelligence table to determine pattern
+- **metadata dict:** memory_types[] (required), namespace/git_repo_name/git_branch/git_commit_hash (optional)
+- **NEVER store secrets** - scan content first | Extract git metadata silently
+- **Validation:** At least one of user_preference or project_id must be provided
+
+**Examples:**
+```
+# ✅ Component (project fact): project_id ONLY
+add-memory(..., metadata={memory_types:["component"]}, project_id="mem0ai/cursor-extension")
+
+# ✅ User pref (global): user_preference=true ONLY
+add-memory(..., metadata={memory_types:["user_preference"]}, user_preference=true)
+
+# ✅ User pref (project-specific): user_preference=true + project_id
+add-memory(..., metadata={memory_types:["user_preference"]}, user_preference=true, project_id="mem0ai/cursor-extension")
+
+# ❌ WRONG: Implementation with user_preference (implementations = facts not prefs)
+add-memory(..., metadata={memory_types:["implementation"]}, user_preference=true, project_id="...")
+```
+
+**list-memories:** Required: project_id | Automatically uses authenticated user's preferences
+
+**delete-memories-by-namespace:** DESTRUCTIVE - ONLY with explicit confirmation | Required: namespaces[] | Optional: user_preference, project_id
+
+## Git Metadata
+Extract before EVERY add-memory and include in metadata dict (silently):
+```bash
+git_repo_name=$(git remote get-url origin 2>/dev/null | sed 's/.*[:/]\([^/]*\/[^.]*\).*/\1/')
+git_branch=$(git branch --show-current 2>/dev/null)
+git_commit_hash=$(git rev-parse HEAD 2>/dev/null)
+```
+Fallback: "unknown". Add all three to metadata dict when calling add-memory.
+
+## Memory Deletion ⚠️ DESTRUCTIVE - PERMANENT
+**Rules:** NEVER suggest | NEVER use proactively | ALWAYS require confirmation
+**Triggers:** "Delete all in [ns]", "Clear [ns]", "Delete my prefs in [ns]"
+**NOT for:** Cleanup questions, outdated memories, general questions
+
+**Confirmation (MANDATORY):**
+1. Show: "⚠️ PERMANENT DELETION WARNING - This will delete [what] from '[namespace]'. Confirm by 'yes'/'confirm'."
+2. Wait for confirmation
+3. If confirmed → execute | If declined → "Deletion cancelled"
+
+**Intent:** "Delete ALL in X" → {namespaces:[X]} | "Delete MY prefs in X" → {namespaces:[X], user_preference:true} | "Delete project facts in X" → {namespaces:[X], project_id} | "Delete my project prefs in X" → {namespaces:[X], user_preference:true, project_id}
+
+## Operating Principles
+1. Phase-based: Initial → Continuous → Store
+2. Checkpoints are BLOCKERS (files, functions, decisions, errors)
+3. Never skip Phase 2
+4. Detailed storage (why > what)
+5. MCP unavailable → mention once, continue
+6. Trust process (early = more searches)
+
+## Session Patterns
+**Empty openmemory.md:** Deep Dive (Phase 1 → analyze → document → Phase 3)
+**Existing:** Read openmemory.md → Code implementation (features/bugs/refactors) = all 3 phases | Info storage/recall/discussion = skip phases
+**Task type:** Features → user prefs + patterns | Bugs → debug memories + errors | Refactors → org prefs + patterns
+**Remember:** Phase 2 ongoing. Search at EVERY checkpoint.
+
+## OpenMemory Guide (openmemory.md)
+Living project index (shareable). Auto-created empty in workspace root.
+
+**Initial Deep Dive:** Phase 1 (2+ searches) → Phase 2 (analyze dirs/configs/frameworks/entry points, search as discovering, extract arch, document Overview/Architecture/User Namespaces/Components/Patterns) → Phase 3 (store with namespaces if fit)
+
+**User Defined Namespaces:** Read before ANY memory op
+- Format: "## User Defined Namespaces\n- [Leave blank - user populates]"
+- Examples: frontend, backend, database
+
+**Storing:** Review content → check namespaces → THINK "domain?" → fits one? assign : omit | Rules: Max ONE, can be NONE, only defined ones
+**Searching:** What searching? → read namespaces → THINK "which could contain?" → cast wide net → use multiple if needed
+
+**Guide Discipline:** Edit directly | Populate as you go | Keep in sync | Update before storing component/implementation/project_info
+**Update Workflow:** Open → update section → save → store via MCP
+**Integration:** Component → Components | Implementation → Patterns | Project info → Overview/Arch | Debug/pref → memory only
+
+**🚨 CRITICAL: Before storing ANY memory, review and update openmemory.md - after every edit verify the guide reflects current system architecture (most important project artifact)**
+
+## Security Guardrails
+**NEVER store:** API keys/tokens, passwords, hashes, private keys, certs, env secrets, OAuth/session tokens, connection strings with creds, AWS keys, webhook secrets, SSH/GPG keys
+**Detection:** Token/Bearer/key=/password= patterns → DO NOT STORE | Base64 in auth → DO NOT STORE | = + long alphanumeric → VERIFY | Doubt → DO NOT STORE, ask
+**Instead store:** Redacted versions ("<YOUR_TOKEN>"), patterns ("uses bearer token"), instructions ("Set TOKEN env")
+**Other:** No destructive ops without approval | User says "save/remember" → IMMEDIATE storage | Think deserves storage → ASK FIRST for prefs | User asks to store secrets → REFUSE
+
+**Remember:** Memory system = effectiveness over time. Rich reasoning > code. When doubt, store. Guide = shareable index.

package/template/README.md

@@ -0,0 +1,29 @@
+# Project Name
+
+This project uses Spec-Driven Development (SDD) with the Project Operating System (POS).
+
+## Getting Started
+
+1. Open this project in Cursor
+2. Run `/spec/init` to begin defining your project specification
+3. Follow the SDD workflow: spec → plan → task → validate
+
+## Workflow
+
+```txt
+/spec/init
+/spec/refine   (optional, repeatable)
+/spec/plan
+/task/start
+[work]
+/task/validate
+```
+
+## Project Structure
+
+- `spec/` - Source of truth (specifications)
+- `work/` - Execution artifacts (milestones, tasks)
+- `.cursor/` - POS rules and commands
+
+For more information, see the POS documentation in `.cursor/rules/`.
+

package/template/spec/00-root-spec.md

@@ -0,0 +1,29 @@
+# Project Root Specification
+
+## 1. Idea Overview
+Describe the idea in broad terms.
+What problem does this project aim to solve?
+
+## 2. Motivation
+Why does this project exist?
+What makes it worth building?
+
+## 3. Target Users
+Who is this for?
+(Keep it high-level; personas can come later.)
+
+## 4. Core Value
+What is the main value delivered to users?
+
+## 5. Initial Scope
+What feels in-scope right now?
+What explicitly feels out-of-scope?
+
+## 6. Open Questions
+List uncertainties, assumptions, or things that need clarification.
+
+## 7. Early Risks & Concerns
+Only include risks that are already visible at this stage.
+
+## 8. Notes
+Anything else discovered during discussion or research.