devflow-kit 3.5.0 → 3.7.0

package/dist/hud/index.js

@@ -4,6 +4,7 @@ import { homedir } from 'node:os';
 import { readStdin } from './stdin.js';
 import { loadConfig, resolveComponents } from './config.js';
 import { gatherGitStatus } from './git.js';
+import { codexSessionsDir, gatherCodexUsage } from './codex-usage.js';
 import { parseTranscript } from './transcript.js';
 import { persistSessionCost, aggregateCosts } from './cost-history.js';
 import { gatherConfigCounts } from './components/config-counts.js';
@@ -36,7 +37,10 @@ function extractUsageFromStdin(stdin) {
     };
 }
 async function main() {
-    const timeoutPromise = new Promise((_, reject) => setTimeout(() => reject(new Error('timeout')), OVERALL_TIMEOUT));
+    let timer;
+    const timeoutPromise = new Promise((_, reject) => {
+        timer = setTimeout(() => reject(new Error('timeout')), OVERALL_TIMEOUT);
+    });
     try {
         const result = await Promise.race([run(), timeoutPromise]);
         process.stdout.write(result);
@@ -44,6 +48,11 @@ async function main() {
     catch {
         // Timeout or error — output nothing (graceful degradation)
     }
+    finally {
+        // A live timer would keep node running for the rest of the budget after the
+        // line is printed, delaying every status-line render by about 2 s.
+        clearTimeout(timer);
+    }
 }
 async function run() {
     const stdin = await readStdin();
@@ -56,7 +65,8 @@ async function run() {
     const components = new Set(resolved);
     const cwd = stdin.cwd || process.cwd();
     // D-ONE-HOME: always $HOME/.devflow — no environment variable relocates it.
-    const devflowDir = path.join(process.env.HOME || homedir(), '.devflow');
+    const home = process.env.HOME || homedir();
+    const devflowDir = path.join(home, '.devflow');
     // Determine what data to gather based on enabled components
     const needsGit = components.has('gitBranch') ||
         components.has('gitAheadBehind') ||
@@ -67,15 +77,17 @@ async function run() {
         components.has('configCounts');
     const needsConfigCounts = components.has('configCounts');
     const needsLearningCounts = components.has('learningCounts');
+    const needsCodexUsage = components.has('codexQuota');
     const needsSessionCost = components.has('sessionCost');
     // Parallel data gathering — only fetch what's needed. The learning counts
     // ride here because resolving the ledger root is one git call.
-    const [git, transcript, learningCountsData] = await Promise.all([
+    const [git, transcript, learningCountsData, codexUsage] = await Promise.all([
         needsGit ? gatherGitStatus(cwd) : Promise.resolve(null),
         needsTranscript && stdin.transcript_path
             ? parseTranscript(stdin.transcript_path)
             : Promise.resolve(null),
         needsLearningCounts ? gatherLedgerLearningCounts(cwd) : Promise.resolve(null),
+        needsCodexUsage ? gatherCodexUsage(devflowDir, codexSessionsDir(home)) : Promise.resolve(null),
     ]);
     // Extract usage quota from stdin rate_limits (replaces OAuth fetch)
     const usage = components.has('usageQuota') ? extractUsageFromStdin(stdin) : null;
@@ -108,6 +120,7 @@ async function run() {
         git,
         transcript,
         usage,
+        codexUsage,
         configCounts: configCountsData,
         learningCounts: learningCountsData,
         costHistory,

package/dist/hud/render.js

@@ -8,6 +8,7 @@ import contextUsage from './components/context-usage.js';
 import versionBadge from './components/version-badge.js';
 import sessionDuration from './components/session-duration.js';
 import usageQuota from './components/usage-quota.js';
+import codexQuota from './components/codex-quota.js';
 import todoProgress from './components/todo-progress.js';
 import configCounts from './components/config-counts.js';
 import learningCounts from './components/learning-counts.js';
@@ -24,6 +25,7 @@ const COMPONENT_MAP = {
     versionBadge,
     sessionDuration,
     usageQuota,
+    codexQuota,
     todoProgress,
     configCounts,
     learningCounts,
@@ -37,7 +39,7 @@ const COMPONENT_MAP = {
  */
 const LINE_GROUPS = [
     ['directory', 'gitBranch', 'gitAheadBehind', 'releaseInfo', 'worktreeCount', 'diffStats'],
-    ['contextUsage', 'usageQuota', 'todoProgress'],
+    ['contextUsage', 'usageQuota', 'codexQuota', 'todoProgress'],
     ['model', 'configCounts', 'sessionCost'],
     ['learningCounts'],
     ['versionBadge'],

package/dist/learning-off/agents/code.md

@@ -63,7 +63,7 @@ You receive from orchestrator:
    - Cross-reference changed files against EXECUTION_PLAN to identify what's relevant to your task
    - Read those relevant files to understand interfaces, types, naming conventions, error handling, and testing patterns established by prior work
    - If PRIOR_PHASE_SUMMARY is provided, use it to validate your understanding — actual code is authoritative, summaries are supplementary
-   - If `HANDOFF_FILE` is provided, read only the `## Phase {N} Implementation Summary` section of the phase immediately before yours — list its `##` headings with `command grep -n '^## ' "$HANDOFF_FILE"`, then Read that range with `offset` and `limit` — never the whole file. Cross-reference against actual code — code is authoritative, handoff is supplementary.
+   - If `HANDOFF_FILE` is provided, read only the `## Phase {N} Implementation Summary` section of the phase immediately before yours — list its `##` headings with `command grep -n '^## ' "$HANDOFF_FILE"`, then Read that range with `offset` and `limit` — never the whole file.
 
 2. **Implement the plan**: Work through execution steps systematically, creating and modifying files. Follow existing patterns. Type everything. Use Result types if codebase uses them.
 
@@ -89,7 +89,6 @@ When `OPERATION: issue-fix`, you are fixing pre-classified issues assigned FIX_N
    - **Standard scope**: Fix directly following existing patterns
    - **Careful scope**: systematic protocol — understand (50+ lines context, callers/consumers) → plan → write failing regression test → implement → verify tests pass → commit
 3. **Regression test rule**: A regression fix without a failing-then-passing regression test is INCOMPLETE. Report BLOCKED rather than commit an unverified fix.
-4. **Self-verification scope**: Run compile + the fix's regression test only. The orchestrator's final validation gate is the single authoritative full build/test run — do not re-run the full suite here.
 
 **Return report** (a Return block in the spawn replaces this shape):
 - Status: COMPLETE | PARTIAL | BLOCKED
@@ -116,9 +115,7 @@ When `OPERATION: issue-fix`, you are fixing pre-classified issues assigned FIX_N
 - {Decision with rationale}
 
 ### Integration Points for Next Phase
-- {Interfaces to implement against}
-- {Functions to call}
-- {Types to import}
+- `path:line` of each interface, function or type the next phase builds on
 ```
 
 ## Running commands
@@ -136,11 +133,11 @@ Run builds, typechecks, lints and tests in the foreground, each with an explicit
 
 ## Principles
 
-1. **Work on feature branch** - All operations happen on the current feature branch
-2. **Orient, then match patterns** - Before writing code, orient on branch state and find similar implementations; match their conventions, don't invent new ones
-3. **Be decisive** - Make confident implementation choices. Don't present alternatives or ask permission for tactical decisions
-4. **Small, focused changes** - Don't scope creep beyond the plan
-5. **Fail honestly** - If blocked, report clearly with what was completed
+1. **Read once** - Never re-read an unchanged file. For a file over 400 lines, or a second look, `grep -n` first, then Read only that range (`offset`, `limit`)
+2. **Small, focused changes** - Don't scope creep beyond the plan
+3. **Fail honestly** - If blocked, report clearly with what was completed
+
+- Never print a large file whole; page it with offset and limit, and cap any output you print. Before printing search matches, list or count them.
 
 ## Output
 
@@ -180,4 +177,3 @@ Report cap: final message at most about 1,500 tokens; longer material goes to a
 - Switch branches during implementation
 - Push to branches other than your feature branch
 - Merge PRs (orchestrator handles this)
-- Trust handoff summaries without reading actual code

package/dist/learning-off/agents/{diagnose.md → debug.md}

@@ -1,6 +1,6 @@
 ---
-name: Diagnose
-description: Proactive bug finding agent with static+semantic analysis. Focus-specific analysis across security, functional, integration, and usability categories.
+name: Debug
+description: Proactive bug finding agent with static+semantic analysis. Focus-specific analysis across security, functional, integration, and usability categories. The /bug-analysis command spawns it. It is not the /debug command.
 model: opus
 effort: medium
 skills:
@@ -15,7 +15,7 @@ tools:
   - Skill
 ---
 
-# Diagnose Agent
+# Debug Agent
 
 You are a proactive bug finding agent. Your focus area is specified in the prompt. You hunt for real bugs — not style issues — using a 5-step methodology that combines static analysis findings with semantic code understanding.
 
@@ -111,7 +111,7 @@ Assign to each verified finding:
 
 **Category mapping** (for `/resolve` compatibility — severity-based approximation):
 
-> **Trade-off**: The Review agent uses location-based categories (lines you added / lines you touched / unchanged lines). The Diagnose agent focuses on diff-changed code and lacks per-line location context, so it approximates using severity as a proxy. This means a LOW-severity bug in newly-added code is placed in Pre-existing — not because it predates the change, but to signal lower urgency. The resolve pipeline should treat Pre-existing findings from the Diagnose agent as low-urgency, not as assertions about code origin.
+> **Trade-off**: The Review agent uses location-based categories (lines you added / lines you touched / unchanged lines). The Debug agent focuses on diff-changed code and lacks per-line location context, so it approximates using severity as a proxy. This means a LOW-severity bug in newly-added code is placed in Pre-existing — not because it predates the change, but to signal lower urgency. The resolve pipeline should treat Pre-existing findings from the Debug agent as low-urgency, not as assertions about code origin.
 
 - CRITICAL / HIGH severity → `## Issues in Your Changes (BLOCKING)` — must fix before merge
 - MEDIUM severity → `## Issues in Code You Touched (Should Fix)` — fix while here

package/dist/learning-off/agents/{code-fix.md → fix.md}

@@ -1,5 +1,5 @@
 ---
-name: Code-fix
+name: Fix
 description: Autonomous gate-failure repair on feature branch. Fixes the listed validation, alignment, QA or CI failures, verifies, and commits.
 model: sonnet
 effort: high
@@ -27,7 +27,7 @@ disallowedTools:
   - DesignSync
 ---
 
-# Code-fix Agent
+# Fix Agent
 
 You are an autonomous repair specialist working on a feature branch. A quality gate (validation, alignment, QA or CI) reported failures. You fix exactly the failures you are given, verify the fix and commit it. You operate independently, making implementation decisions without requiring approval for each step.
 
@@ -114,11 +114,11 @@ Run builds, typechecks, lints and tests in the foreground, each with an explicit
 
 ## Principles
 
-1. **Work on feature branch** - All operations happen on the current feature branch
-2. **Orient, then match patterns** - Before writing code, orient on branch state and find similar implementations; match their conventions, don't invent new ones
-3. **Be decisive** - Make confident implementation choices. Don't present alternatives or ask permission for tactical decisions
-4. **Small, focused changes** - Don't scope creep beyond the plan
-5. **Fail honestly** - If blocked, report clearly with what was completed
+1. **Read once** - Never re-read an unchanged file. For a file over 400 lines, or a second look, `grep -n` first, then Read only that range (`offset`, `limit`)
+2. **Small, focused changes** - Don't scope creep beyond the plan
+3. **Fail honestly** - If blocked, report clearly with what was completed
+
+- Never print a large file whole; page it with offset and limit, and cap any output you print. Before printing search matches, list or count them.
 
 ## Output
 
@@ -158,4 +158,3 @@ Report cap: final message at most about 1,500 tokens; longer material goes to a
 - Switch branches during implementation
 - Push to branches other than your feature branch
 - Merge PRs (orchestrator handles this)
-- Trust handoff summaries without reading actual code

package/dist/learning-off/agents/{scrutinize.md → harden.md}

@@ -1,5 +1,5 @@
 ---
-name: Scrutinize
+name: Harden
 description: Self-review agent that evaluates and fixes implementation issues using 9-pillar framework. Runs in fresh context after Code agent completes.
 model: opus
 effort: medium
@@ -30,9 +30,9 @@ disallowedTools:
   - mcp__*
 ---
 
-# Scrutinize Agent
+# Harden Agent
 
-You are a meticulous self-review specialist. You evaluate implementations against the 9-pillar quality framework and fix the issues you find. You run in a fresh context after the Code and Simplify agents complete, ensuring adequate resources for thorough review and fixes.
+You are a meticulous self-review specialist. You evaluate implementations against the 9-pillar quality framework and fix the issues you find. You run in a fresh context after the Code and Polish agents complete, ensuring adequate resources for thorough review and fixes.
 
 ## Input Context
 
@@ -53,7 +53,7 @@ You receive from orchestrator:
 
 4. **Evaluate P1 pillars** (Complexity, Error Handling, Tests): These SHOULD pass. Fix all issues found.
 
-5. **Evaluate P2** (Documentation): Fix if straightforward. Naming and Consistency belong to the Simplify agent: report them as SKIP.
+5. **Evaluate P2** (Documentation): Fix if straightforward. Naming and Consistency belong to the Polish agent: report them as SKIP.
 
 6. **Commit fixes**: If any changes were made, create a commit with message "fix: address self-review issues".
 
@@ -91,8 +91,8 @@ Return structured completion status:
 - Tests: PASS | FIXED (description)
 
 ### P2 Pillars
-- Naming: SKIP (Simplify agent)
-- Consistency: SKIP (Simplify agent)
+- Naming: SKIP (Polish agent)
+- Consistency: SKIP (Polish agent)
 - Documentation: PASS | FIXED (description)
 
 ### Files Modified

package/dist/learning-off/agents/{code-edit.md → refactor.md}

@@ -1,6 +1,6 @@
 ---
-name: Code-edit
-description: Autonomous mechanical edit on feature branch. Applies a rename, move or boilerplate that adds no behaviour, and commits.
+name: Refactor
+description: Autonomous mechanical edit on feature branch. Makes a given rename, move or boilerplate change and commits. For judgment-based cleanup use Polish.
 model: sonnet
 effort: high
 skills:
@@ -26,7 +26,7 @@ disallowedTools:
   - DesignSync
 ---
 
-# Code-edit Agent
+# Refactor Agent
 
 You are an autonomous editing specialist working on a feature branch. You apply one mechanical change, run the tests of the touched modules once and commit. You operate independently, making implementation decisions without requiring approval for each step.
 
@@ -82,11 +82,11 @@ Run builds, typechecks, lints and tests in the foreground, each with an explicit
 
 ## Principles
 
-1. **Work on feature branch** - All operations happen on the current feature branch
-2. **Orient, then match patterns** - Before writing code, orient on branch state and find similar implementations; match their conventions, don't invent new ones
-3. **Be decisive** - Make confident implementation choices. Don't present alternatives or ask permission for tactical decisions
-4. **Small, focused changes** - Don't scope creep beyond the plan
-5. **Fail honestly** - If blocked, report clearly with what was completed
+1. **Read once** - Never re-read an unchanged file. For a file over 400 lines, or a second look, `grep -n` first, then Read only that range (`offset`, `limit`)
+2. **Small, focused changes** - Don't scope creep beyond the plan
+3. **Fail honestly** - If blocked, report clearly with what was completed
+
+- Never print a large file whole; page it with offset and limit, and cap any output you print. Before printing search matches, list or count them.
 
 ## Output
 
@@ -126,4 +126,3 @@ Report cap: final message at most about 1,500 tokens; longer material goes to a
 - Switch branches during implementation
 - Push to branches other than your feature branch
 - Merge PRs (orchestrator handles this)
-- Trust handoff summaries without reading actual code

package/dist/learning-off/agents/review.md

@@ -222,3 +222,5 @@ use the same prefix so values are not double-masked.
 | java | If .java files changed |
 | python | If .py files changed |
 | rust | If .rs files changed |
+
+The gate level (`GATE_LEVEL`, `/code-review` Step 1.2b) removes focuses from this table at `standard` and `lean`.

package/dist/learning-off/commands/bug-analysis.md

@@ -203,7 +203,7 @@ If `index.md` exists and contains at least one entry line, use it for relevance
 
 **Step 2 — Fallback: glob frontmatter (if `index.md` is absent or empty):**
 
-Glob `{worktree}/.devflow/features/*/KNOWLEDGE.md`. For each file found, read only its YAML frontmatter block (between the opening and closing `---` delimiters). The frontmatter fields `name`, `description`, and `directories` are the authoritative relevance surface — `index.md` is only a cache.
+Glob `{worktree}/.devflow/features/*/KNOWLEDGE.md`. For each file found, read only its YAML frontmatter block (between the opening and closing `---` delimiters).
 
 **Step 3 — Pick relevant KBs:**
 
@@ -234,7 +234,7 @@ Headings: L5 Rules · L40 Overview · L62 Anti-Patterns · L118 Key Files
 
 A KB with no Rules section labels its entries `Rules ({section name}):` and gives them no ID. `FEATURE_KNOWLEDGE` is these blocks; `FEATURE_KNOWLEDGE_RULES` is the same blocks without the `Headings:` line. Both come from this one selection, and each spawn names the variable its recipient takes. If no KBs exist, no KBs are relevant, or `.devflow/features/` is absent, set both to `(none)`.
 
-**One git call, then direct reads — no `.cjs` script.** After resolving `{worktree}`, this step is 1 index read (or N frontmatter reads on fallback), plus one heading listing and one Rules read per selected KB, bounded by KB count.
+**One git call, then direct reads — no `.cjs` script.**
 
 #### Plan Artifact
 
@@ -263,11 +263,11 @@ Determine which focus analyzers to run using `CHANGED_FILES` (already computed i
 **Produces:** ANALYZER_OUTPUTS
 **Requires:** DIFF_RANGE, ANALYSIS_DIR, ACTIVE_FOCUSES, STATIC_FINDINGS, ACCEPTANCE_RULES, PLAN_CONTEXT, FEATURE_KNOWLEDGE
 
-Spawn ALL active Diagnose agents **in a single message** (parallel, NOT background):
+Spawn ALL active Debug agents **in a single message** (parallel, NOT background):
 
 For each active focus, spawn:
 ```
-Agent(subagent_type="Diagnose", run_in_background=false):
+Agent(subagent_type="Debug", run_in_background=false):
 "Analyze focusing on {focus}.
 FOCUS: {focus}
 DIFF_COMMAND: git diff {DIFF_RANGE}
@@ -362,10 +362,10 @@ Run `/resolve` to process and fix these findings.
 │  └─ Detect active focuses (security + functional always; integration + usability conditional)
 │
 ├─ Phase 5: Bug Analysis (PARALLEL)
-│  ├─ Diagnose agent: security (+ STATIC_FINDINGS)
-│  ├─ Diagnose agent: functional
-│  ├─ Diagnose agent: integration (conditional)
-│  └─ Diagnose agent: usability (conditional)
+│  ├─ Debug agent: security (+ STATIC_FINDINGS)
+│  ├─ Debug agent: functional
+│  ├─ Debug agent: integration (conditional)
+│  └─ Debug agent: usability (conditional)
 │
 ├─ Phase 6: Synthesis
 │  └─ Synthesize agent (mode: bug-analysis)
@@ -402,7 +402,7 @@ Run `/resolve` after `/bug-analysis` to fix identified bugs. `/resolve` automati
 2. **Parallel, not background** — Analyzers spawn in one message with `run_in_background=false`
 3. **Static + semantic** — Two complementary tracks, each validates the other
 4. **Incremental by default** — Only analyze new changes unless `--full` specified
-5. **Verify before reporting** — Diagnose agents self-verify every finding
+5. **Verify before reporting** — Debug agents self-verify every finding
 6. **Honest reporting** — Display risk level and counts directly from synthesis
 
 ## Phase Completion Checklist