rafcode 3.0.0 → 3.8.0

package/src/parsers/codex-stream-renderer.ts

@@ -9,21 +9,44 @@
  * - TodoList: Task tracking (skipped)
  */
 
+import type { UsageData } from '../types/config.js';
 import type { RenderResult } from './stream-renderer.js';
 
 export interface CodexEvent {
   type: string;
-  /** AgentMessage fields */
+  id?: string;
+  model?: string;
+  /** Claude flat-format fields (AgentMessage) */
   content?: string;
-  /** CommandExecution fields */
+  /** Claude flat-format fields (CommandExecution) */
   command?: string;
   exit_code?: number;
-  /** FileChange fields */
+  /** Claude flat-format fields (FileChange) */
   file_path?: string;
   change_kind?: string;
-  /** McpToolCall fields */
+  /** Claude flat-format fields (McpToolCall) */
   tool_name?: string;
   server_name?: string;
+  /** Real Codex nested item (for item.completed / item.started) */
+  item?: {
+    type: string;
+    text?: string;
+    command?: string;
+    exit_code?: number;
+    path?: string;
+    change_kind?: string;
+    message?: string;
+  };
+  /** Error message (for error / turn.failed events) */
+  message?: string;
+  /** Nested error object (for turn.failed events) */
+  error?: { message?: string };
+  /** Usage data (for turn.completed events) */
+  usage?: {
+    input_tokens?: number;
+    output_tokens?: number;
+    total_tokens?: number;
+  };
 }
 
 function truncate(text: string, maxLen: number): string {
@@ -65,6 +88,23 @@ export function renderCodexStreamEvent(line: string): RenderResult {
       // Skip todo list events - minimal noise
       return { display: '', textContent: '' };
 
+    // Real Codex CLI event types (nested format)
+    case 'item.completed':
+      return renderItemCompleted(event);
+
+    case 'item.started':
+      // Skip started events — we render on completion
+      return { display: '', textContent: '' };
+
+    case 'turn.completed':
+      return renderTurnCompleted(event);
+
+    case 'error':
+      return renderError(event);
+
+    case 'turn.failed':
+      return renderTurnFailed(event);
+
     default:
       // Skip unknown event types gracefully
       return { display: '', textContent: '' };
@@ -106,3 +146,108 @@ function renderMcpToolCall(event: CodexEvent): RenderResult {
     textContent: '',
   };
 }
+
+// --- Real Codex CLI event handlers (nested format) ---
+
+function renderItemCompleted(event: CodexEvent): RenderResult {
+  const item = event.item;
+  if (!item) return { display: '', textContent: '' };
+
+  switch (item.type) {
+    case 'agent_message': {
+      const text = item.text ?? '';
+      return {
+        display: text ? text + '\n' : '',
+        textContent: text,
+      };
+    }
+    case 'command_execution': {
+      const cmd = item.command ?? '';
+      const exitCode = item.exit_code ?? 0;
+      const status = exitCode === 0 ? '✓' : `✗ exit ${exitCode}`;
+      return {
+        display: `  → Running: ${truncate(cmd, 120)} [${status}]\n`,
+        textContent: '',
+      };
+    }
+    case 'file_change': {
+      const filePath = item.path ?? 'unknown';
+      const kind = item.change_kind ?? 'modified';
+      return {
+        display: `  → File ${kind}: ${filePath}\n`,
+        textContent: '',
+      };
+    }
+    case 'error': {
+      const msg = item.message ?? 'Unknown error';
+      return {
+        display: `  ✗ Error: ${msg}\n`,
+        textContent: msg,
+      };
+    }
+    default:
+      return { display: '', textContent: '' };
+  }
+}
+
+function renderTurnCompleted(event: CodexEvent): RenderResult {
+  const usageData = extractUsageData(event);
+
+  if (event.usage) {
+    const { input_tokens, output_tokens } = event.usage;
+    const parts: string[] = [];
+    if (input_tokens !== undefined) parts.push(`in: ${input_tokens}`);
+    if (output_tokens !== undefined) parts.push(`out: ${output_tokens}`);
+    if (parts.length > 0) {
+      return {
+        display: `  → Usage: ${parts.join(', ')}\n`,
+        textContent: '',
+        usageData,
+      };
+    }
+  }
+  return { display: '', textContent: '', usageData };
+}
+
+function extractUsageData(event: CodexEvent): UsageData | undefined {
+  if (!event.usage) {
+    return undefined;
+  }
+
+  const modelId = event.model ?? 'codex';
+  const inputTokens = event.usage.input_tokens ?? 0;
+  const outputTokens = event.usage.output_tokens ?? 0;
+
+  return {
+    inputTokens,
+    outputTokens,
+    cacheReadInputTokens: 0,
+    cacheCreationInputTokens: 0,
+    modelUsage: {
+      [modelId]: {
+        inputTokens,
+        outputTokens,
+        cacheReadInputTokens: 0,
+        cacheCreationInputTokens: 0,
+        costUsd: null,
+      },
+    },
+    totalCostUsd: null,
+  };
+}
+
+function renderError(event: CodexEvent): RenderResult {
+  const msg = event.message ?? 'Unknown error';
+  return {
+    display: `  ✗ Error: ${msg}\n`,
+    textContent: msg,
+  };
+}
+
+function renderTurnFailed(event: CodexEvent): RenderResult {
+  const msg = event.error?.message ?? event.message ?? 'Turn failed';
+  return {
+    display: `  ✗ Failed: ${msg}\n`,
+    textContent: msg,
+  };
+}

package/src/prompts/amend.ts

@@ -6,7 +6,6 @@ export interface AmendPromptParams {
   existingTasks: Array<DerivedTask & { taskName: string }>;
   nextTaskNumber: number;
   newTaskDescription: string;
-  worktreeMode?: boolean;
 }
 
 export interface AmendPromptResult {
@@ -25,9 +24,7 @@ export function getAmendPrompt(params: AmendPromptParams): AmendPromptResult {
     existingTasks,
     nextTaskNumber,
     newTaskDescription,
-    worktreeMode,
   } = params;
-  const worktreeFlag = worktreeMode ? ' --worktree' : '';
 
   const existingTasksSummary = existingTasks
     .map((task) => {
@@ -59,15 +56,14 @@ export function getAmendPrompt(params: AmendPromptParams): AmendPromptResult {
       ? modifiableTasks.map((t) => `- Task ${t.id}: ${t.taskName}`).join('\n')
       : '(none)';
 
-  const systemPrompt = `You are a project planning assistant for RAF (Ralph's Automation Framework). Your task is to ADD NEW TASKS or MODIFY PENDING tasks in an existing project.
+  const systemPrompt = `You are a project planning assistant for RAF (Ralph's Automation Framework). Add new tasks or modify pending tasks in an existing project.
 
-## IMPORTANT: Amendment Mode
+## Amendment Mode
 
-You are in AMENDMENT MODE. This means:
-- You MAY modify [MODIFIABLE] tasks (pending/failed) if the user requests changes
-- NEVER modify [PROTECTED] tasks (completed) - their outcomes depend on the original plan
-- DO NOT renumber existing tasks
-- You can create NEW tasks starting from number ${encodeTaskId(nextTaskNumber)}
+- [PROTECTED] tasks (completed): NEVER modify — their outcomes depend on the original plan
+- [MODIFIABLE] tasks (pending/failed): MAY modify if the user requests changes
+- Do NOT renumber existing tasks
+- New tasks start from number ${encodeTaskId(nextTaskNumber)}
 
 ## Project Location
 
@@ -75,54 +71,30 @@ Project folder: ${projectPath}
 
 ## Existing Tasks
 
-The following tasks already exist in this project:
-
 ${existingTasksSummary}
 
-### Protected Tasks (COMPLETED - cannot be modified)
+### Protected (COMPLETED)
 ${protectedTasksList}
 
-### Modifiable Tasks (PENDING/FAILED - can be modified if requested)
+### Modifiable (PENDING/FAILED)
 ${modifiableTasksList}
 
 ## Instructions
 
 ### Step 1: Read Context
 
-First, read the original project description from:
-- ${projectPath}/input.md
-
-And review existing decisions from:
-- ${projectPath}/decisions.md (if it exists)
+Read the original project description (\`${projectPath}/input.md\`) and existing decisions (\`${projectPath}/decisions.md\`, if it exists).
 
 ### Step 2: Analyze New Requirements
 
-Read the user's description of new tasks and identify what needs to be added. Consider:
-- How the new tasks relate to existing ones
-- Dependencies on completed tasks (check the ## Dependencies section in existing plan files)
-- Whether new tasks should reference existing task outcomes
-
-**Identifying Follow-up Tasks**: When a new task is a follow-up, fix, or iteration of a previously completed task, you MUST reference the previous task's outcome in the new plan's Context section. This gives the executing agent full context about what was done before.
-
-Use this format in the Context section:
+Consider how new tasks relate to existing ones and their dependencies. For follow-up/fix tasks, reference the previous task's outcome in the Context section:
 \`This is a follow-up to task NN. See outcome: {projectPath}/outcomes/NN-task-name.md\`
 
-The outcome file paths for completed tasks are listed above in the Existing Tasks section.
-
 ### Step 3: Interview the User
 
-For EACH new task you identify, use the AskUserQuestion tool to gather:
-- Specific requirements and constraints
-- Technology preferences
-- Any existing code or patterns to follow
-- Edge cases to handle
-
-### Step 3.5: Record Decisions
+For EACH new task, use AskUserQuestion to gather specific requirements, technology preferences, existing patterns, and edge cases.
 
-After EACH interview question is answered, append the Q&A pair to the existing decisions file:
-- ${projectPath}/decisions.md
-
-Use this format:
+After EACH answer, append the Q&A to \`${projectPath}/decisions.md\`:
 \`\`\`markdown
 ## [Question asked]
 [User's answer]
@@ -130,12 +102,9 @@ Use this format:
 
 ### Step 4: Create New Plan Files
 
-After interviewing the user about all NEW tasks, create plan files starting from the next available number:
-- ${projectPath}/plans/${encodeTaskId(nextTaskNumber)}-task-name.md
-- ${projectPath}/plans/${encodeTaskId(nextTaskNumber + 1)}-task-name.md
-- etc.
+Create plan files starting from \`${projectPath}/plans/${encodeTaskId(nextTaskNumber)}-task-name.md\`. Use kebab-case names.
 
-Each plan file MUST have Obsidian-style frontmatter at the top, before the \`# Task:\` heading. The frontmatter uses standard YAML format with opening and closing \`---\` delimiters:
+Each plan file MUST have this structure:
 
 \`\`\`markdown
 ---
@@ -144,95 +113,51 @@ effort: medium
 # Task: [Task Name]
 
 ## Objective
-[Clear, one-sentence description of what this task accomplishes]
+[Clear, one-sentence description]
 
 ## Context
-[Why this task is needed, how it fits into the larger project]
-[Reference relevant existing tasks if applicable]
-[For follow-up/fix tasks: "This is a follow-up to task NN. See outcome: {projectPath}/outcomes/NN-task-name.md"]
+[Why this task is needed, relation to existing tasks]
+[For follow-ups: "This is a follow-up to task NN. See outcome: {projectPath}/outcomes/NN-task-name.md"]
 
 ## Dependencies
-[Optional section - omit if task has no dependencies]
-[Comma-separated list of task IDs this task depends on, e.g., "1, 2"]
-[If a dependency fails, this task will be automatically blocked]
+[Optional — omit if none. Comma-separated task IDs, e.g., "1, 2"]
 
 ## Requirements
-[Specific requirements gathered from the user interview]
 - Requirement 1
 - Requirement 2
-- ...
 
 ## Implementation Steps
 1. [Step 1]
 2. [Step 2]
-3. [Step 3]
-...
 
 ## Acceptance Criteria
 - [ ] Criterion 1
 - [ ] Criterion 2
-- [ ] All tests pass
 
 ## Notes
-[Any additional context, warnings, or considerations]
-[Reference to existing task outcomes if relevant]
-\`\`\`
-
-### Frontmatter Requirements
-
-The \`effort\` field is REQUIRED in every plan file. It indicates task complexity and determines which model will execute the task:
-- \`effort: low\` — Trivial/mechanical changes, simple one-file edits, config changes
-- \`effort: medium\` — Well-scoped feature work, bug fixes with clear plans, multi-file changes following existing patterns
-- \`effort: high\` — Architectural changes, complex logic, tasks requiring deep codebase understanding
-
-Optionally, you can add an explicit \`model\` field to override the effort-based model selection:
-\`\`\`markdown
----
-effort: medium
-model: opus
----
-# Task: ...
+[Additional context, warnings, references to existing task outcomes]
 \`\`\`
 
-This is rarely needed — prefer using the \`effort\` label so the user's config controls the actual model used.
+**Frontmatter fields:**
+- \`effort\` (REQUIRED): \`low\` (trivial/mechanical), \`medium\` (well-scoped feature work), \`high\` (architectural/complex)
+- \`model\` (optional): Override effort-based model selection. Rarely needed.
 
 ### Step 5: Confirm Completion
 
-After creating all new plan files:
-1. Provide a summary of:
-   - The new tasks you've created, including the effort level for each task. Example format:
-     - Task 2: add-caching (effort: medium)
-     - Task 3: update-docs (effort: low)
-   - How they relate to existing tasks
-   - Total task count in the project
-2. Display this exit message to the user:
+Summarize new tasks with effort levels, their relation to existing tasks, and total task count. Then display:
 
 \`\`\`
 Planning complete! To exit this session and run your tasks:
   1. Press Ctrl-C twice to exit
-  2. Then run: raf do <project>${worktreeFlag}
+  2. Then run: raf do <project>
 \`\`\`
 
-## Important Rules
-
-1. NEVER modify COMPLETED task plans - they are [PROTECTED] because their outcomes depend on the original plan
-2. You MAY modify non-completed task plans (pending/failed) if the user requests changes - they are [MODIFIABLE]
-3. ALWAYS interview the user before creating or modifying plans
-4. New tasks start from number ${encodeTaskId(nextTaskNumber)}
-5. Use descriptive, kebab-case names for plan files
-6. Each plan should be self-contained with all context needed
-7. Specify task dependencies using the ## Dependencies section with task IDs only (e.g., "1, 2")
-8. Tasks without dependencies should omit the Dependencies section entirely
-9. Be specific - vague plans lead to poor execution
-10. ALWAYS include the \`effort\` frontmatter field in every plan file — assess each task's complexity
-
-## Plan Output Style
-
-Plans can include whatever level of detail you deem helpful for the executing agent. Use your judgment:
-- Include implementation details when they clarify the approach
-- Code snippets are acceptable when they help illustrate a specific pattern
-- File paths are helpful when referencing existing project files, patterns, or directories
-- Focus on clarity — the goal is for the executing agent to understand what needs to be done`;
+## Rules
+
+- Always interview the user before creating or modifying plans
+- Each plan must be self-contained with all context needed
+- Be specific — vague plans lead to poor execution
+- Include implementation details, code snippets, and file paths when they clarify the approach`;
 
   const userMessage = `I want to add the following new tasks to this project: