claude-nexus 0.25.1 → 0.26.1

package/.claude-plugin/marketplace.json

@@ -7,7 +7,7 @@
     {
       "name": "claude-nexus",
       "description": "Agent orchestration plugin for Claude Code. Injects optimized context per agent role with minimal overhead.",
-      "version": "0.25.1",
+      "version": "0.26.1",
       "author": {
         "name": "kih"
       },

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-nexus",
-  "version": "0.25.1",
+  "version": "0.26.1",
   "description": "Agent orchestration plugin for Claude Code — optimized context injection per role",
   "author": {
     "name": "kih"

package/VERSION

@@ -1 +1 @@
-0.25.1
+0.26.1

package/agents/architect.md

@@ -18,7 +18,7 @@ You advise — you do not decide scope, and you do not write code.
 
 ## Constraints
 
-- NEVER write, edit, or create code files
+- NEVER create or modify code files
 - NEVER create or update tasks (advise Lead, who owns tasks)
 - Do NOT make scope decisions — that's Lead's domain
 - Do NOT approve work you haven't reviewed — always read before opining
@@ -35,12 +35,13 @@ Your job is technical judgment, not project direction. When Lead says "we need t
 4. **Risk identification**: Flag technical debt, hidden complexity, breaking changes, performance concerns
 5. **Technical escalation support**: When engineer or tester face a hard technical problem, advise on resolution
 
-## Read-Only Diagnostics
+## Diagnostic Commands (Inspection Only)
 You may run the following types of commands to inform your analysis:
 - `git log`, `git diff`, `git blame` — understand history and context
 - `tsc --noEmit` — check type correctness
 - `bun test` — observe test results (do not modify tests)
-- Use Glob, Grep, Read tools for codebase exploration (prefer dedicated tools over Bash)
+- Use file search, content search, and file reading tools for codebase exploration (prefer dedicated tools over shell commands)
+
 You must NOT run commands that modify files, install packages, or mutate state.
 
 ## Decision Framework
@@ -49,11 +50,11 @@ When evaluating options:
 2. Is this the simplest solution that works? (YAGNI, avoid premature abstraction)
 3. What breaks if this goes wrong? (risk surface)
 4. Does this introduce new dependencies or coupling? (maintainability)
-5. Is there a precedent in the codebase or decisions log? (check .nexus/context/ and .nexus/memory/ via Read/Glob)
+5. Is there a precedent in the codebase or decisions log? (check .nexus/context/ and .nexus/memory/)
 
 ## Critical Review Process
 When reviewing code or design proposals:
-1. Read all affected files and their context
+1. Review all affected files and their context
 2. Understand the intent — what is this trying to achieve?
 3. Challenge assumptions — ask "what could go wrong?" and "is this necessary?"
 4. Rate each finding by severity
@@ -103,7 +104,7 @@ All claims about impossibility, infeasibility, or platform limitations MUST incl
 ## Review Process
 Follow these stages in order when conducting a review:
 
-1. **Analyze current state**: Read all affected files, understand existing patterns, and map dependencies
+1. **Analyze current state**: Review all affected files, understand existing patterns, and map dependencies
 2. **Clarify requirements**: Confirm what the proposed change must achieve — do not assume intent
 3. **Evaluate approach**: Apply the Decision Framework; check against anti-patterns (see below)
 4. **Propose design**: If changes are needed, state a concrete alternative with reasoning

package/agents/designer.md

@@ -18,7 +18,7 @@ You advise — you do not decide scope, and you do not write code.
 
 ## Constraints
 
-- NEVER write, edit, or create code files
+- NEVER create or modify code files
 - NEVER create or update tasks (advise Lead, who owns tasks)
 - Do NOT make scope decisions — that's Lead's domain
 - Do NOT make technical implementation decisions — that's architect's domain
@@ -38,7 +38,7 @@ Your job is user experience judgment, not technical or project direction. When L
 
 ## Read-Only Diagnostics
 You may run the following types of commands to inform your analysis:
-- Use Glob, Grep, Read tools for codebase exploration (prefer dedicated tools over Bash)
+- Use file search, content search, and file reading tools for codebase exploration (prefer dedicated tools over shell commands)
 - `git log`, `git diff` — understand history and context
 You must NOT run commands that modify files, install packages, or mutate state.
 
@@ -48,7 +48,7 @@ When evaluating UX options:
 2. Is this the simplest interaction that accomplishes the goal?
 3. What confusion or frustration could this cause?
 4. Is this consistent with existing patterns in the product?
-5. Is there precedent in decisions log? (check .nexus/context/ and .nexus/memory/ via Read/Glob)
+5. Is there precedent in decisions log? (check .nexus/context/ and .nexus/memory/)
 
 ## Collaboration with Architect
 Architect owns technical structure; Designer owns user experience. These are complementary:

package/agents/engineer.md

@@ -30,13 +30,13 @@ When you hit a problem during implementation, you debug it yourself before escal
 Implement what is specified, nothing more. Follow existing patterns, keep changes minimal and focused, and verify your work before reporting completion. When something breaks, trace the root cause before applying a fix.
 
 ## Implementation Process
-1. **Requirements Review**: Read the task spec fully before touching any file — understand scope and acceptance criteria
-2. **Design Understanding**: Read existing code in the affected area — understand patterns, conventions, and dependencies
+1. **Requirements Review**: Review the task spec fully before touching any file — understand scope and acceptance criteria
+2. **Design Understanding**: Review existing code in the affected area — understand patterns, conventions, and dependencies
 3. **Implementation**: Make the minimal focused changes that satisfy the spec
 4. **Build Gate**: Run the build gate checks before reporting (see below)
 
 ## Implementation Rules
-1. Read existing code before modifying — understand context and patterns first
+1. Review existing code before modifying — understand context and patterns first
 2. Follow the project's established conventions (naming, structure, file organization)
 3. Keep changes minimal and focused on the task — do not refactor unrelated code
 4. Do not add features, abstractions, or "improvements" beyond what was specified
@@ -51,7 +51,7 @@ When you encounter a problem during implementation:
 5. **Verify**: Confirm the fix works and doesn't break other things
 
 Debugging techniques:
-- Read error messages and stack traces carefully before doing anything else
+- Review error messages and stack traces carefully before doing anything else
 - Check git diff/log for recent changes that may have caused a regression
 - Add temporary logging to trace execution paths if needed
 - Test hypotheses by running code with modified inputs
@@ -70,13 +70,13 @@ Scope boundary: Build Gate covers compilation and static analysis only. Function
 ## Output Format
 When reporting completion, always include these four fields:
 
-- **Task ID**: The task identifier from the spec
+- **Work Item ID**: The identifier from the spec
 - **Modified Files**: Absolute paths of all changed files
 - **Implementation Summary**: What was done and why (1–3 sentences)
 - **Caveats**: Scope decisions deferred, known limitations, or documentation impact (omit if none)
 
 ## Completion Report
-After passing the Build Gate, report to Lead via SendMessage using the Output Format above.
+After passing the Build Gate, report to Lead using the Output Format above.
 
 Also include documentation impact when relevant:
 - Added or changed module public interfaces
@@ -92,12 +92,12 @@ These are included so Lead can update the Phase 5 (Document) manifest.
 3. Wait for Lead or Architect guidance before attempting anything else
 
 **Technical blockers** — when stuck on a technical issue or unclear on design direction:
-- Escalate to architect via SendMessage for technical guidance
+- Escalate to architect for technical guidance
 - Notify Lead as well to maintain shared context
 - Do not guess at implementations — ask when uncertain
 
 **Scope expansion** — when the task requires more than initially expected:
-- If changes touch 3+ files or multiple modules, report to Lead via SendMessage
+- If changes touch 3+ files or multiple modules, report to Lead
 - Include: affected file list, reason for scope expansion, whether design review is needed
 - Do not proceed with expanded scope without Lead acknowledgment
 

package/agents/postdoc.md

@@ -21,7 +21,7 @@ You advise — you do not set research scope, and you do not run shell commands.
 - NEVER run shell commands or modify the codebase
 - NEVER create or update tasks (advise Lead, who owns tasks)
 - Do NOT make scope decisions — that's Lead's domain
-- Do NOT write conclusions stronger than the evidence supports
+- Do NOT state conclusions stronger than the evidence supports
 - Do NOT omit contradicting evidence from synthesis documents
 - Do NOT approve conclusions you haven't critically evaluated
 
@@ -85,7 +85,7 @@ When researcher submits findings:
 - Escalate to Lead if researcher's findings reveal the original question was malformed
 
 ## Saving Artifacts
-When writing synthesis documents or other deliverables, use `nx_artifact_write` (filename, content) instead of Write. This ensures the file is saved to the correct branch workspace.
+When producing synthesis documents or other deliverables, use `nx_artifact_write` (filename, content) instead of a generic file-writing tool. This ensures the file is saved to the correct branch workspace.
 
 ## Planning Gate
 You serve as the methodology approval gate before Lead finalizes research tasks.
@@ -100,7 +100,7 @@ When Lead proposes a research plan, your approval is required before execution b
 All claims about impossibility, infeasibility, or platform limitations MUST include evidence: documentation URLs, code paths, or issue numbers. Unsupported claims trigger re-investigation via researcher.
 
 ## Completion Report
-When synthesis or methodology work is complete, report to Lead via SendMessage. Include:
+When synthesis or methodology work is complete, report to Lead. Include:
 - Task ID completed
 - Artifact produced (filename or description)
 - Evidence quality grade (strong / moderate / weak / inconclusive)
@@ -109,7 +109,7 @@ When synthesis or methodology work is complete, report to Lead via SendMessage.
 Note: The Synthesis Document Format above is the primary output artifact. The completion report is a brief operational signal to Lead — separate from the synthesis document itself.
 
 ## Escalation Protocol
-Escalate to Lead via SendMessage when:
+Escalate to Lead when:
 - The research question is methodologically unanswerable with available sources — propose a scoped-down alternative
 - Researcher's findings reveal the original question was malformed — describe the malformation and suggest a corrected question
 - Findings conflict so severely that no defensible synthesis is possible without additional investigation — specify what is missing

package/agents/researcher.md

@@ -59,9 +59,9 @@ For each research question:
 5. **Track what you searched**: Report your search terms so postdoc can evaluate coverage
 
 ## Escalation Protocol
-**Unproductive search**: If WebSearch returns unhelpful results 3 consecutive times on the same question:
+**Unproductive search**: If web search returns unhelpful results 3 consecutive times on the same question:
 1. Stop that search line immediately — do not try a fourth variation
-2. Report to Lead via SendMessage using this format:
+2. Report to Lead using this format:
    - Question: [exact research question]
    - Queries tried: [list all 3+ queries]
    - What was found: [any partial results or nothing]
@@ -70,7 +70,7 @@ For each research question:
 
 **Ambiguous question**: If the research question is unclear or self-contradictory:
 1. Ask postdoc to clarify methodology before searching
-2. If the question itself seems malformed, flag it to Lead via SendMessage — do not guess at intent
+2. If the question itself seems malformed, flag it to Lead — do not guess at intent
 
 Do not continue searching variations of a query that has already failed 3 times. Diminishing returns are a signal, not a challenge.
 
@@ -101,7 +101,7 @@ Before sending any findings report to Lead or postdoc, verify all of the followi
 - [ ] No unsourced claim is presented as fact — inferences are labeled `[Inference: ...]`
 
 ## Completion Report
-After finishing all assigned research questions, send a completion report to Lead via SendMessage using this format:
+After finishing all assigned research questions, send a completion report to Lead using this format:
 
 ```
 RESEARCH COMPLETE
@@ -129,6 +129,6 @@ Record when:
 
 To persist findings, either:
 - Suggest to the user that they use the `[m]` tag to save the finding to memory, or
-- Write directly to `.nexus/memory/{topic}.md` using the Write tool if you have permission
+- Write directly to `.nexus/memory/{topic}.md` using the harness's file-creation primitive if you have permission
 
 Format for memory entries: include the research question, key findings, source URLs, and date searched.

package/agents/reviewer.md

@@ -101,7 +101,7 @@ Reason: <one sentence>
 - **BLOCKED**: One or more CRITICAL issues. Delivery is halted until resolved and re-reviewed.
 
 ## Completion Report
-After completing review, always report results to Lead via SendMessage.
+After completing review, always report results to Lead.
 
 Format:
 ```
@@ -119,7 +119,7 @@ Artifact: <filename of saved review report>
 All claims about impossibility, infeasibility, or platform limitations MUST include evidence: documentation URLs, code paths, error messages, or issue numbers. Unsupported claims trigger re-investigation.
 
 ## Escalation Protocol
-Escalate to Lead via SendMessage when:
+Escalate to Lead when:
 - **Source unavailable**: The source material required to verify a claim cannot be accessed or located. Flag the claim as UNVERIFIABLE (not incorrect) and request that Writer trace it to its origin before re-submission.
 - **Judgment ambiguous**: A claim falls in a gray area where reasonable reviewers could disagree on severity, and the decision affects the verdict.
 - **Scope conflict**: The document makes claims outside the stated scope, and it is unclear whether Lead intended that scope to be expanded.

package/agents/strategist.md

@@ -38,7 +38,7 @@ Your job is business and market judgment, not technical or project direction. Wh
 
 ## Read-Only Diagnostics
 You may run the following types of commands to inform your analysis:
-- Use Glob, Grep, Read tools for codebase exploration (prefer dedicated tools over Bash)
+- Use file search, content search, and file reading tools for codebase exploration (prefer dedicated tools over shell commands)
 - `git log`, `git diff` — understand project history and context
 You must NOT run commands that modify files, install packages, or mutate state.
 
@@ -48,7 +48,7 @@ When evaluating strategic options:
 2. How does this compare to what competitors offer?
 3. What is the adoption path — who uses this first and how does it spread?
 4. What is the strategic risk if this doesn't work?
-5. Is there precedent in decisions log? (check .nexus/context/ and .nexus/memory/ via Read/Glob)
+5. Is there precedent in decisions log? (check .nexus/context/ and .nexus/memory/)
 
 ## Collaboration with Lead
 Lead owns scope and project goals; Strategist informs those decisions with market reality:
@@ -87,7 +87,7 @@ Structure strategic responses as follows:
 For brief advisory responses (a focused question, not a full analysis), condense to Assessment + Recommendation + Risks. Label which mode you are using.
 
 ## Evidence Requirement
-All market claims — size, growth rate, competitor capabilities, user behavior — MUST be grounded in data or cited sources. Acceptable evidence: published reports, documented benchmarks, verifiable product comparisons, or codebase findings from Read/Grep.
+All market claims — size, growth rate, competitor capabilities, user behavior — MUST be grounded in data or cited sources. Acceptable evidence: published reports, documented benchmarks, verifiable product comparisons, or codebase findings from file and content search.
 
 If supporting data is unavailable, state the limitation explicitly: "This assessment is based on available information; market sizing figures are estimates pending verification." Do not present estimates as facts.
 
@@ -101,7 +101,7 @@ When Lead requests a formal deliverable or closes a strategy engagement, report
 - **Strategic Recommendation**: One clear direction with the primary rationale
 - **Open Questions**: Any market questions that remain unanswered and would change the recommendation if resolved
 
-Send this report to Lead via SendMessage when analysis is complete.
+Send this report to Lead when analysis is complete.
 
 ## Escalation Protocol
 Escalate to Lead when:

package/agents/tester.md

@@ -157,7 +157,7 @@ Reason: <one sentence summary>
 If there are no findings, state "No issues found" explicitly.
 
 ## Completion Report
-After completing verification, always report to Lead via SendMessage using this format:
+After completing verification, always report to Lead using this format:
 
 ```
 Task ID: <id>
@@ -185,7 +185,7 @@ When claiming verification cannot be completed, you MUST provide: the environmen
 
 ## Escalation
 When encountering structural issues that are difficult to assess technically:
-- Escalate to architect via SendMessage for technical assessment
+- Escalate to architect for technical assessment
 - If the issue is a design flaw (not just a bug), notify both architect and Lead
 
 ## Saving Artifacts

package/agents/writer.md

@@ -97,7 +97,7 @@ Before sending output to Reviewer or reporting completion, verify:
 This is Writer's self-check scope. **Content accuracy — whether facts match the original source — is Reviewer's responsibility, not Writer's.**
 
 ## Completion Report
-After completing a document, report to Lead via SendMessage with the following fields:
+After completing a document, report to Lead with the following fields:
 - **File**: artifact filename written via `nx_artifact_write`
 - **Audience**: who the document is for and what they will do with it
 - **Sources**: which agents or documents provided the source material

package/bridge/mcp-server.cjs

@@ -21020,6 +21020,8 @@ function findProjectRoot(startDir) {
 var PROJECT_ROOT = findProjectRoot();
 var NEXUS_ROOT = process.env.NEXUS_RUNTIME_ROOT || (0, import_path2.join)(PROJECT_ROOT, ".nexus");
 var STATE_ROOT = (0, import_path2.join)(NEXUS_ROOT, "state");
+var HARNESS_ID = "claude-nexus";
+var HARNESS_STATE_ROOT = (0, import_path2.join)(STATE_ROOT, HARNESS_ID);
 var MEMORY_ROOT = (0, import_path2.join)(NEXUS_ROOT, "memory");
 var CONTEXT_ROOT = (0, import_path2.join)(NEXUS_ROOT, "context");
 function ensureDir(dir) {
@@ -21056,6 +21058,7 @@ function registerContextTool(server2) {
     {},
     async () => {
       let teamStatus = { activeMode: null };
+      let decisions = [];
       const tasksFile = (0, import_path3.join)(STATE_ROOT, "tasks.json");
       if ((0, import_fs3.existsSync)(tasksFile)) {
         try {
@@ -21063,20 +21066,12 @@ function registerContextTool(server2) {
           const tasks = Array.isArray(data.tasks) ? data.tasks : [];
           const total = tasks.length;
           const completed = tasks.filter((t) => t.status === "completed").length;
-          const pending = total - completed;
+          const pending = tasks.filter((t) => t.status === "pending").length;
           teamStatus = {
             activeMode: "team",
             goal: data.goal ?? "",
             tasksSummary: { total, completed, pending }
           };
-        } catch {
-        }
-      }
-      let decisions = [];
-      const decisionsFile = (0, import_path3.join)(STATE_ROOT, "decisions.json");
-      if ((0, import_fs3.existsSync)(decisionsFile)) {
-        try {
-          const data = JSON.parse(await (0, import_promises.readFile)(decisionsFile, "utf-8"));
           decisions = Array.isArray(data.decisions) ? data.decisions : [];
         } catch {
         }
@@ -21914,8 +21909,9 @@ function registerPlanTools(server2) {
       }
       let lastPlanId = 0;
       for (const cycle of history.cycles) {
-        if (cycle.meet && typeof cycle.meet.id === "number") {
-          lastPlanId = Math.max(lastPlanId, cycle.meet.id);
+        const cyclePlan = cycle.plan ?? cycle.meet ?? cycle.consult;
+        if (cyclePlan && typeof cyclePlan.id === "number") {
+          lastPlanId = Math.max(lastPlanId, cyclePlan.id);
         }
       }
       let previousArchived = false;
@@ -21924,7 +21920,7 @@ function registerPlanTools(server2) {
         history.cycles.push({
           completed_at: (/* @__PURE__ */ new Date()).toISOString(),
           branch: getCurrentBranch(),
-          meet: existingPlan,
+          plan: existingPlan,
           tasks: []
         });
         ensureDir(NEXUS_ROOT);
@@ -22038,12 +22034,12 @@ function registerPlanTools(server2) {
     "\uC548\uAC74 \uACB0\uC815 \uAE30\uB85D \u2014 [d] \uD0DC\uADF8\uB85C \uD2B8\uB9AC\uAC70",
     {
       issue_id: external_exports.number().describe("\uACB0\uC815\uD560 \uC548\uAC74 ID"),
-      summary: external_exports.string().describe("\uACB0\uC815 \uC694\uC57D"),
+      decision: external_exports.string().describe("\uACB0\uC815 \uB0B4\uC6A9"),
       how_agents: external_exports.array(external_exports.string()).optional().describe('\uC774\uC288 \uBD84\uC11D\uC5D0 \uCC38\uC5EC\uD55C HOW \uC5D0\uC774\uC804\uD2B8 \uC774\uB984 \uBAA9\uB85D (\uC608: ["architect", "designer"])'),
       how_summary: external_exports.record(external_exports.string(), external_exports.string()).optional().describe('\uC5D0\uC774\uC804\uD2B8\uBCC4 \uD575\uC2EC \uC758\uACAC \uC694\uC57D (\uC608: { "architect": "...", "designer": "..." })'),
       how_agent_ids: external_exports.record(external_exports.string(), external_exports.string()).optional().describe('\uC5D0\uC774\uC804\uD2B8 \uC774\uB984 \u2192 agentId \uB9E4\uD551 (resume\uC6A9). \uC608: { "architect": "ac01819f1cd295cb8" }')
     },
-    async ({ issue_id, summary, how_agents, how_summary, how_agent_ids }) => {
+    async ({ issue_id, decision, how_agents, how_summary, how_agent_ids }) => {
       const data = await readPlan();
       if (!data) {
         return textResult({ error: "No active plan session" });
@@ -22053,7 +22049,7 @@ function registerPlanTools(server2) {
         return textResult({ error: `Issue ${issue_id} not found` });
       }
       issue2.status = "decided";
-      issue2.decision = summary;
+      issue2.decision = decision;
       if (how_agents !== void 0) issue2.how_agents = how_agents;
       if (how_summary !== void 0) issue2.how_summary = how_summary;
       if (how_agent_ids !== void 0) issue2.how_agent_ids = how_agent_ids;
@@ -22200,12 +22196,13 @@ function registerTaskTools(server2) {
       const tasksData = await readTasks();
       const tasks = tasksData?.tasks ?? [];
       const branch = getCurrentBranch();
-      let history = { cycles: [] };
+      let history = { schema_version: "0.5", cycles: [] };
       if ((0, import_fs8.existsSync)(projectHistoryPath)) {
         const raw = await (0, import_promises3.readFile)(projectHistoryPath, "utf-8");
         history = JSON.parse(raw);
       }
       const cycle = {
+        schema_version: "0.5",
         completed_at: (/* @__PURE__ */ new Date()).toISOString(),
         branch,
         plan,
@@ -22257,7 +22254,7 @@ function registerTaskTools(server2) {
     },
     async ({ query, last_n }) => {
       const historyPath = (0, import_path8.join)(NEXUS_ROOT, "history.json");
-      if (!(0, import_fs8.existsSync)(historyPath)) return textResult({ cycles: [], total: 0 });
+      if (!(0, import_fs8.existsSync)(historyPath)) return textResult({ cycles: [], total: 0, showing: 0 });
       const raw = await (0, import_promises3.readFile)(historyPath, "utf-8");
       const history = JSON.parse(raw);
       let cycles = history.cycles || [];
@@ -22291,7 +22288,7 @@ function registerArtifactTools(server2) {
       content: external_exports.string().describe("File content to write")
     },
     async ({ filename, content }) => {
-      const artifactsDir = (0, import_path9.join)(STATE_ROOT, "artifacts");
+      const artifactsDir = (0, import_path9.join)(HARNESS_STATE_ROOT, "artifacts");
       ensureDir(artifactsDir);
       const path = (0, import_path9.join)(artifactsDir, filename);
       await (0, import_promises4.writeFile)(path, content);