chorus-cli 0.4.2 → 0.4.5

package/index.js

@@ -18,6 +18,43 @@ const execPromise = util.promisify(exec);
 const execFilePromise = util.promisify(execFile);
 const fs = require('fs').promises;
 
+// Returns a stable hardware UUID for this machine, with a persistent fallback
+async function getMachineId() {
+  try {
+    if (process.platform === 'darwin') {
+      const { stdout } = await execPromise(
+        "ioreg -rd1 -c IOPlatformExpertDevice | awk -F'\"' '/IOPlatformUUID/{print $4}'"
+      );
+      if (stdout.trim()) return stdout.trim();
+    } else if (process.platform === 'linux') {
+      const fsp = require('fs').promises;
+      const id = (await fsp.readFile('/etc/machine-id', 'utf8')).trim();
+      if (id) return id;
+    } else if (process.platform === 'win32') {
+      const { stdout } = await execPromise('wmic csproduct get UUID');
+      const lines = stdout.trim().split('\n');
+      if (lines.length > 1) {
+        const uuid = lines[1].trim();
+        if (uuid && uuid !== 'FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF') return uuid;
+      }
+    }
+  } catch { /* fall through to persistent fallback */ }
+
+  // Persistent fallback: generate and cache a random UUID
+  const configDir = path.join(os.homedir(), '.config', 'chorus');
+  const idPath = path.join(configDir, 'machine-id');
+  try {
+    const existing = await fs.readFile(idPath, 'utf8');
+    if (existing.trim()) return existing.trim();
+  } catch { /* no file yet */ }
+
+  const { randomUUID } = require('crypto');
+  const newId = randomUUID();
+  await fs.mkdir(configDir, { recursive: true });
+  await fs.writeFile(idPath, newId + '\n');
+  return newId;
+}
+
 // Run coder.py with real-time stderr streaming so progress is visible
 function runCoder(prompt) {
   return new Promise((resolve, reject) => {
@@ -26,6 +63,9 @@ function runCoder(prompt) {
       env.CHORUS_API_KEY = CONFIG.ai.chorusApiKey;
       env.CHORUS_API_URL = CONFIG.ai.chorusApiUrl;
     }
+    if (CONFIG.ai.machineId) {
+      env.CHORUS_MACHINE_ID = CONFIG.ai.machineId;
+    }
     const proc = spawn(CONFIG.ai.venvPython, [CONFIG.ai.coderPath, '--prompt', prompt], {
       cwd: process.cwd(),
       env,
@@ -77,6 +117,9 @@ function runQAChat(issue, enrichedDetails, qaName, useSuper = false) {
       env.CHORUS_API_KEY = CONFIG.ai.chorusApiKey;
       env.CHORUS_API_URL = CONFIG.ai.chorusApiUrl;
     }
+    if (CONFIG.ai.machineId) {
+      env.CHORUS_MACHINE_ID = CONFIG.ai.machineId;
+    }
     if (CONFIG.messenger === 'slack' && CONFIG.slack.botToken) {
       env.SLACK_BOT_TOKEN = CONFIG.slack.botToken;
     }
@@ -194,10 +237,14 @@ IMPORTANT: Output ONLY the message above. Do not include any preamble, thinking
     if (!CONFIG.ai.chorusApiKey) {
       throw new Error('CHORUS_API_KEY environment variable is required. Run "chorus setup" to configure.');
     }
-    const openai = new OpenAI({
+    const openaiOpts = {
       apiKey: CONFIG.ai.chorusApiKey,
       baseURL: CONFIG.ai.chorusApiUrl,
-    });
+    };
+    if (CONFIG.ai.machineId) {
+      openaiOpts.defaultHeaders = { 'X-Machine-Id': CONFIG.ai.machineId };
+    }
+    const openai = new OpenAI(openaiOpts);
     
     const response = await openai.chat.completions.create({
       model: 'anthropic/claude-opus-4',
@@ -506,6 +553,9 @@ async function processTicket(issueArg, { useSuper = false, skipQA = false, qaNam
   try {
     console.log('🚀 Starting ticket processing...\n');
 
+    // Resolve machine fingerprint for per-machine usage tracking
+    CONFIG.ai.machineId = await getMachineId();
+
     // 0. Ensure Python venv exists and has required dependencies
     const reqFile = path.join(__dirname, 'tools', 'requirements.txt');
     const { execFileSync: efs } = require('child_process');
@@ -869,6 +919,9 @@ async function setupProxyAuth() {
 
   const baseUrl = CONFIG.ai.chorusApiUrl.replace(/\/v1\/?$/, '');
 
+  // Resolve machine fingerprint so the server can track per-machine usage
+  const machineId = await getMachineId();
+
   // Try register first, fall back to login if already registered
   let apiKey;
   try {
@@ -895,11 +948,11 @@ async function setupProxyAuth() {
     });
 
     console.log('   Registering...');
-    let res = await doPost(`${baseUrl}/auth/register`, { email, password });
+    let res = await doPost(`${baseUrl}/auth/register`, { email, password, machineId });
 
     if (res.status === 409 || (res.body && res.body.error && res.body.error.includes('already'))) {
       console.log('   Account exists, logging in...');
-      res = await doPost(`${baseUrl}/auth/login`, { email, password });
+      res = await doPost(`${baseUrl}/auth/login`, { email, password, machineId });
     }
 
     if (res.status >= 400) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "chorus-cli",
-  "version": "0.4.2",
+  "version": "0.4.5",
   "description": "Automated ticket resolution with AI, Teams, and Slack integration",
   "main": "index.js",
   "bin": {

package/tools/coder.py

@@ -50,40 +50,161 @@ def is_token_limit_error(err):
     return "token limit exceeded" in msg or "rate_limit_error" in msg
 
 SYSTEM_PROMPT = """\
-You are a coding agent running in the terminal.
+You are a coding agent. You receive a GitHub/Azure DevOps issue, a codebase map, \
+and optionally a QA conversation with clarified requirements. Your job is to \
+implement the changes and produce a clean, working diff.
+
 Working directory: {cwd}
 
-You help with software engineering tasks: writing code, debugging, refactoring, \
-explaining code, running commands, and managing files.
-
-Formatting:
-- Your output is displayed raw in a terminal. Never use markdown.
-- No ## headers, **bold**, *italic*, [links](url), or bullet symbols like -.
-- Use blank lines, indentation, and CAPS for emphasis or section labels.
-- Use plain numbered lists (1. 2. 3.) when listing things.
-- For inline code references, just use the name directly (e.g. myFunction, not `myFunction`).
-- Keep responses short and scannable.
-
-{approach}Guidelines:
-- Be direct and concise. No filler.
-- Always use your tools. If a question can be answered by running a command (git, ls, etc.), use the bash tool — never guess.
-- Always read a file before editing it.
-- If edit_file fails with "old_string not found", re-read the file to get the actual current content before retrying. Never guess at file contents.
-- Use edit_file for targeted changes. Use write_file for new files or complete rewrites.
-- Prefer editing existing files over creating new ones.
-- Do not write new unit tests unless the project already has substantive test coverage.
-- Do not attempt to build or compile the project.
-- Don't add unnecessary comments, docstrings, or type annotations.
-- For bash commands, prefer non-interactive commands.
-- When asked about the codebase, use list_files and search_files to explore it.
-"""
 
-APPROACH_BLOCK = """\
-Approach:
-- Before making changes, read the relevant files and briefly state your approach.
-- For multi-file changes, outline which files you'll modify and in what order.
-- Do not start editing until you understand the existing code.
+OUTPUT FORMAT
+
+Your output is displayed raw in a terminal. Never use markdown.
+No headings with #, no **bold**, no *italic*, no `backticks`, no [links](url),
+no bullet characters like - or *.
+Use blank lines and indentation for structure. Use CAPS for section labels.
+Use plain numbered lists (1. 2. 3.) when listing things.
+Refer to code identifiers by name directly (e.g. myFunction not `myFunction`).
+No greetings, preambles, encouragement, or sign-offs.
+No "Great question!", "Let me", "Sure!", "I'll now", or similar filler.
+State what you are doing, then do it. After completing work, state what changed.
+
+
+HOW YOU WORK
+
+You operate in three strict phases: Plan, Execute, Verify. Do not blend them.
+
+
+PHASE 1: PLAN (before writing any code)
+
+Read the issue, QA conversation (if provided), and codebase map. Then produce a
+written plan with exactly these sections:
+
+UNDERSTANDING:
+What the issue is asking for in one sentence.
+
+QUESTIONS STILL OPEN:
+Anything unresolved from QA. If --skip-qa was used, list assumptions you are making
+and flag them clearly. Prefer the conservative/conventional choice for each.
+
+FILES TO READ:
+The minimum set of existing files you need to examine to understand the patterns,
+interfaces, and conventions. Maximum 8 files. Justify each.
+
+FILES TO CREATE:
+New files with their paths and a one-line description of contents.
+
+FILES TO MODIFY:
+Existing files with a one-line description of what changes.
+
+APPROACH:
+How you will implement this in 2-4 sentences. Reference specific patterns
+from the codebase map.
+
+Do not proceed to Phase 2 until your plan is complete.
+
+
+PHASE 2: EXECUTE
+
+Implement the plan. Follow these rules:
+
+Reading files:
+  Only use read_file on files listed in your plan. If you discover you need another
+  file, note why -- but if you have read more than 12 files total, stop and
+  re-evaluate your plan. You are exploring, not implementing.
+  The one exception to reading a file again: if edit_file fails because old_string
+  was not found, re-read that file to get its current content before retrying.
+
+Writing code:
+  Follow existing patterns exactly. Match the conventions you observed for: naming,
+  exports, file structure, import ordering, indentation, and comment style.
+  Write complete files. Do not leave TODOs, placeholders, or "implement this" comments.
+  If the issue asks for a tool/script, it must work non-interactively (accept arguments
+  or config, not interactive prompts) unless the issue explicitly requires interactivity.
+
+Shell commands (bash tool):
+  You may run bash for: installing dependencies, running the project's existing
+  linter, running the project's existing tests, checking TypeScript compilation.
+  You may not run bash for: exploratory searching beyond what was in your plan,
+  reading files you did not plan to read, testing scripts with improvised piped input.
+  Use read_file, list_files, and search_files instead of bash with cat, find, or grep.
+  Maximum 10 bash commands total. If you are approaching this limit, you are doing
+  too much exploration or too much debugging. Ship what you have.
+
+
+PHASE 3: VERIFY
+
+Before declaring done:
+
+1. List every file you created or modified.
+2. For each, confirm it is syntactically valid (ran linter or compiler if available).
+3. If tests exist for the area you changed, run them and confirm they pass.
+4. If you wrote a script/CLI tool, show the --help output or a dry-run invocation.
+5. Write the PR description:
+   Title: conventional commit format (feat:, fix:, chore:, etc.)
+   Body: what changed, why, any assumptions made, anything the reviewer should
+   look at carefully.
+
+
+BUDGET DISCIPLINE
+
+You have a token budget. You do not know exactly how large it is, but you must act
+as though it could run out at any time. This means:
+
+  Front-load the high-value work. Write the actual implementation code early. File
+  exploration is not progress -- committed code is progress.
+
+  Do not retry the same failing approach. If something fails twice, choose a different
+  approach or simplify. Do not iterate more than twice on the same problem.
+
+  If you are 60% through your work and something fundamental is broken, stop. Produce
+  what you have, note what is incomplete, and let the human finish. A partial, clean
+  implementation is more valuable than a complete, broken one.
+
+  No yak-shaving. If the issue says "create a screen scaffolding tool," build the tool.
+  Do not also create a demo script, a markdown doc, a bash wrapper, and sample outputs.
+  Deliver the core ask first. Only add extras if the implementation is solid and you
+  have headroom.
+
+
+WHAT NOT TO DO
+
+  Do not explore the filesystem to "understand the project." The codebase map already
+  gives you the structure. Read specific files for specific reasons.
+
+  Do not overuse list_files, search_files, or bash for exploration. This is the single
+  most common failure mode. Each call costs tokens and time. If you need more than 3
+  exploratory calls, your plan was insufficient -- go back and improve the plan.
+
+  Do not create interactive scripts that require stdin. They are untestable in this
+  environment and will waste your budget on failed pipe attempts.
+
+  Do not create documentation, READMEs, or demo files unless the issue asks for them.
+
+  Do not modify package.json, CI configs, or project infrastructure unless the issue
+  specifically requires it.
+
+  Do not keep going when you are stuck. If you have spent more than 2 attempts debugging
+  the same problem, note the issue, deliver what works, and move on.
+
+
+ON AMBIGUITY
+
+When requirements are unclear and no QA conversation was provided:
+1. State your assumption explicitly in the plan.
+2. Choose the most conventional/standard approach.
+3. Note the assumption in the PR description so the reviewer can catch disagreements early.
+Do not guess ambitiously. Guess conservatively. A correct simple implementation beats
+a broken ambitious one.
+
+
+TOOL USAGE
 
+  Always use read_file before editing a file.
+  If edit_file fails with "old_string not found", re-read the file with read_file to
+  get the actual current content before retrying. Never guess at file contents.
+  Use edit_file for targeted changes. Use write_file for new files or complete rewrites.
+  Prefer editing existing files over creating new ones.
 """
 
 # ── Tool Definitions ────────────────────────────────────────────────────────
@@ -692,7 +813,7 @@ def run_prompt(client, prompt, system):
     
     plan_messages = [
         {"role": "system", "content": system},
-        {"role": "user", "content": f"{prompt}\n\nBefore making any code changes, please analyze this issue and explain:\n1. What is the problem/goal?\n2. What files do you need to examine first?\n3. What is your overall approach to solving this?\n4. Which files will you modify and how?\n\nDo NOT write any code yet - just explain your plan."}
+        {"role": "user", "content": f"{prompt}\n\nExecute Phase 1 (Plan) now. Produce the plan using the exact sections from your instructions: UNDERSTANDING, QUESTIONS STILL OPEN, FILES TO READ, FILES TO CREATE, FILES TO MODIFY, APPROACH. Do NOT write any code yet."}
     ]
     
     try:
@@ -924,8 +1045,12 @@ def main():
         sys.exit(1)
 
     base_url = os.environ.get("CHORUS_API_URL", "https://chorus-bad0f.web.app/v1")
-    client = OpenAI(api_key=api_key, base_url=base_url)
-    system = SYSTEM_PROMPT.format(cwd=os.getcwd(), approach=APPROACH_BLOCK)
+    machine_id = os.environ.get("CHORUS_MACHINE_ID")
+    client_kwargs = {"api_key": api_key, "base_url": base_url}
+    if machine_id:
+        client_kwargs["default_headers"] = {"X-Machine-Id": machine_id}
+    client = OpenAI(**client_kwargs)
+    system = SYSTEM_PROMPT.format(cwd=os.getcwd())
 
     # Load codebase map if available
     map_file = Path.cwd() / ".coder" / "map.md"

package/tools/qa.py

@@ -403,7 +403,11 @@ Write a clear numbered list of requirements. Each requirement should be specific
 def run_qa_chat(issue_context, messenger, qa_name):
     api_key = os.environ.get("CHORUS_API_KEY")
     base_url = os.environ.get("CHORUS_API_URL", "https://chorus-bad0f.web.app/v1")
-    client = OpenAI(api_key=api_key, base_url=base_url)
+    machine_id = os.environ.get("CHORUS_MACHINE_ID")
+    client_kwargs = {"api_key": api_key, "base_url": base_url}
+    if machine_id:
+        client_kwargs["default_headers"] = {"X-Machine-Id": machine_id}
+    client = OpenAI(**client_kwargs)
     conversation = []
     raw_responses = []