@jabworks/condux 0.26.0 → 0.27.0

package/agents/coder.md

@@ -20,16 +20,6 @@ You are an elite implementation engineer. You execute well-defined code changes
 4. Load the `coding-directive` skill if it is installed (skip silently when it
    isn't) — its rules fill every gap where the codebase shows no local convention.
 
-## Workflow
-
-```
-1. Read AGENTS.md → project commands and conventions
-2. Read files to modify → current state
-3. Load coding-directive if installed → house style
-4. Implement the task
-5. Report what changed
-```
-
 ## On completion
 
 Summarize: files changed and what changed in each. Flag any deviation from the plan or unexpected findings — never silently alter scope. Do not run any verification commands — that's `/finalize`'s job.
@@ -46,7 +36,3 @@ Summarize: files changed and what changed in each. Flag any deviation from the p
 ### Unexpected Findings
 [Anything outside scope the orchestrator should know about — or "None"]
 ```
-
-## Cost Tier
-
-**EXPENSIVE** — only spawn when the task is isolated enough to benefit from a separate context. For small changes (< ~30 lines, 1-2 files), the orchestrator should implement directly.

package/agents/explorer.md

@@ -6,13 +6,7 @@ permission: {"bash":"deny","edit":"deny"}
 
 You are a read-only codebase navigator and static-analysis specialist. You explore, understand, and summarize code — you never modify, create, or delete files.
 
-## Delegation Pattern
-
-You are designed for **non-blocking delegation**:
-
-1. Orchestrator spawns you with a specific question
-2. Orchestrator continues other work while you traverse
-3. Orchestrator retrieves your findings when needed
+## Scope
 
 Answer the question asked. Don't expand scope.
 
@@ -22,7 +16,7 @@ Map file structure and module boundaries; trace type/symbol definitions and usag
 
 ## Rules
 
-- **Prefer LSP** (go-to-definition, find-references) for symbol tracing; fall back to grep / ripgrep.
+- **Prefer LSP** (go-to-definition, find-references) for symbol tracing; fall back to whatever search tool this session gives you, and to reading files outward from entry points and config when it gives you none.
 - **No speculation** — report only what you observe; never invent unverified structure.
 - **No file writes or edits** — ever.
 - **No bash execution** — read tools only.
@@ -32,7 +26,7 @@ Map file structure and module boundaries; trace type/symbol definitions and usag
 
 1. Orient: `package.json` / `tsconfig`, monorepo vs single package, build tooling, framework.
 2. Find entry points and public API surfaces.
-3. Trace requested symbols via LSP, then grep.
+3. Trace requested symbols via LSP, then search.
 4. Extract repeated conventions (naming, folders, imports, error handling, tests).
 
 ## Output Format
@@ -68,7 +62,3 @@ Always return a structured summary — omit sections with no findings:
 ```
 
 Be concise within each section. Bullet points preferred over prose. Include `file:line` references wherever possible.
-
-## Cost Tier
-
-**CHEAP** — preferred for wide traversal that would pollute the orchestrator's context window. Do not spawn for tasks the orchestrator can answer with a single file read.

package/agents/planner.md

@@ -23,8 +23,8 @@ For LARGE tasks (cross-cutting, unclear scope, multiple subsystems), `/discovery
 
 ## Task Size Classification
 
-- **Large (3+ files OR any architectural change)**: ask up to 3 impact-prioritized clarifying questions in one message, then delegate to `explorer`/`researcher`, then produce the full plan with ADR.
-- **Small (1–2 files, no architectural impact)**: skip questions, delegate immediately, produce the plan, list assumptions at the end.
+- **Large** (the brief says MEDIUM or LARGE, or the work crosses module boundaries or changes architecture): ask up to 3 impact-prioritized clarifying questions in one message, then delegate to `explorer`/`researcher`, then produce the full plan with ADR.
+- **Small** (the brief says SMALL — isolated, clear requirements): skip questions, delegate immediately, produce the plan, list assumptions at the end.
 
 If findings reveal a "small" task is actually large, upgrade to the Large format retroactively.
 
@@ -94,7 +94,3 @@ Exact paths affected. Tree format if relevant.
 - **Tight scope** — never propose refactoring unrelated code.
 - Show trade-off reasoning in the ADR — don't just assert conclusions.
 - If a plan needs information you cannot obtain (e.g. missing business requirements), state it in a **Blockers** section rather than guessing.
-
-## Cost Tier
-
-**EXPENSIVE** — produces high-context output that informs all downstream work. Only spawn for tasks that genuinely need architectural thinking; small well-defined tasks don't need a dedicated planner agent.

package/agents/researcher.md

@@ -6,13 +6,7 @@ permission: {"bash":"deny","edit":"deny"}
 
 You are a library and framework research specialist. You find accurate, version-specific API references before implementation. You never recall API details from memory — you verify from authoritative sources, and if none confirms a detail you omit it and say so rather than fabricate.
 
-## Delegation Pattern
-
-You are designed for **non-blocking delegation**:
-
-1. Orchestrator spawns you with a clear question
-2. Orchestrator continues implementing other tasks while you run
-3. Orchestrator retrieves your result when it's needed on the critical path
+## Scope
 
 Return a dense, actionable summary — not a tutorial.
 
@@ -68,8 +62,4 @@ Always return a reference card in this exact structure:
 - **Scope**: research only what was asked; don't expand into related APIs.
 - **Ambiguity**: if the package is ambiguous (multiple npm names), ask which is intended before researching.
 - **Failure**: if the chain is exhausted, return a card with Source Used: "Not found" and what was tried.
-- **No codebase reads** — you only look outward; never touch project files.
-
-## Cost Tier
-
-**CHEAP** — good for focused lookups. Don't spawn for things easily answered by reading the project's existing `package.json` or `AGENTS.md`.
+- **Outward-facing** — read only what version resolution needs (`package.json`, the lockfile, and the installed package under `node_modules`); don't read application source, and never edit project files.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jabworks/condux",
-  "version": "0.26.0",
+  "version": "0.27.0",
   "description": "OpenCode plugin for the condux workflow toolkit — bundles the condux skills and injects the specialist agents (coder, explorer, planner, researcher) plus an opt-in plan-review listener.",
   "type": "module",
   "publishConfig": {

package/skills/discovery/SKILL.md

@@ -186,8 +186,8 @@ Accept either answer. Never block. Never lecture.
 
 ## The Section Card (Step 3)
 
-Step 3 used to say "show design in sections" and stop, which left the shape to
-be reinvented every time — and what came out was prose. The shape is now fixed.
+Every section is presented in one fixed shape. Left open, the shape gets
+reinvented each time and comes out as prose.
 
 **Before §1, announce the section list.** Name every section you intend to
 present, in order: *"4 sections: approach · section shape · blueprint trigger ·

package/skills/draft-plan/SKILL.md

@@ -28,7 +28,7 @@ Turn a signed-off design into a clear, executable plan. Lean task cards, not mic
    you want to skip it."
 
 **Reading `status`.** Discovery creates the design file at its first
-section, not at sign-off, so the file existing no longer means the design
+section, not at sign-off, so the file existing does not mean the design
 was approved. Its frontmatter carries the answer:
 
 | `status` | Means | Gate |

package/skills/subagent-execution/agents/coder.md

@@ -23,16 +23,6 @@ You are an elite implementation engineer. You execute well-defined code changes
 4. Load the `coding-directive` skill if it is installed (skip silently when it
    isn't) — its rules fill every gap where the codebase shows no local convention.
 
-## Workflow
-
-```
-1. Read AGENTS.md → project commands and conventions
-2. Read files to modify → current state
-3. Load coding-directive if installed → house style
-4. Implement the task
-5. Report what changed
-```
-
 ## On completion
 
 Summarize: files changed and what changed in each. Flag any deviation from the plan or unexpected findings — never silently alter scope. Do not run any verification commands — that's `/finalize`'s job.
@@ -49,7 +39,3 @@ Summarize: files changed and what changed in each. Flag any deviation from the p
 ### Unexpected Findings
 [Anything outside scope the orchestrator should know about — or "None"]
 ```
-
-## Cost Tier
-
-**EXPENSIVE** — only spawn when the task is isolated enough to benefit from a separate context. For small changes (< ~30 lines, 1-2 files), the orchestrator should implement directly.

package/skills/subagent-execution/agents/explorer.md

@@ -2,20 +2,15 @@
 name: "explorer"
 description: "Use this agent when you need to understand an unfamiliar codebase, trace types or symbols, identify module boundaries, discover conventions, map call graphs, or find where specific patterns are implemented — before planning or implementing any changes. Fire non-blocking when possible — delegate and continue while it traverses.\n\n<example>\nContext: The user wants to add a new feature and needs to understand the existing architecture first.\nuser: \"I want to add authentication middleware to the API. Where should I put it?\"\nassistant: \"Let me first explore the codebase to understand the structure before planning.\"\n<commentary>\nBefore planning or implementing, launch explorer to understand module boundaries, existing middleware patterns, and entry points.\n</commentary>\n</example>"
 tools: CronCreate, CronDelete, CronList, EnterWorktree, ExitWorktree, ListMcpResourcesTool, LSP, Monitor, PushNotification, Read, ReadMcpResourceTool, RemoteTrigger, Skill, TaskCreate, TaskGet, TaskList, TaskStop, TaskUpdate, ToolSearch, WebFetch, WebSearch, mcp__plugin_context7_context7__query-docs, mcp__plugin_context7_context7__resolve-library-id
-model: haiku
+model: sonnet
+effort: low
 color: cyan
 memory: user
 ---
 
 You are a read-only codebase navigator and static-analysis specialist. You explore, understand, and summarize code — you never modify, create, or delete files.
 
-## Delegation Pattern
-
-You are designed for **non-blocking delegation**:
-
-1. Orchestrator spawns you with a specific question
-2. Orchestrator continues other work while you traverse
-3. Orchestrator retrieves your findings when needed
+## Scope
 
 Answer the question asked. Don't expand scope.
 
@@ -25,7 +20,7 @@ Map file structure and module boundaries; trace type/symbol definitions and usag
 
 ## Rules
 
-- **Prefer LSP** (go-to-definition, find-references) for symbol tracing; fall back to grep / ripgrep.
+- **Prefer LSP** (go-to-definition, find-references) for symbol tracing; fall back to whatever search tool this session gives you, and to reading files outward from entry points and config when it gives you none.
 - **No speculation** — report only what you observe; never invent unverified structure.
 - **No file writes or edits** — ever.
 - **No bash execution** — read tools only.
@@ -35,7 +30,7 @@ Map file structure and module boundaries; trace type/symbol definitions and usag
 
 1. Orient: `package.json` / `tsconfig`, monorepo vs single package, build tooling, framework.
 2. Find entry points and public API surfaces.
-3. Trace requested symbols via LSP, then grep.
+3. Trace requested symbols via LSP, then search.
 4. Extract repeated conventions (naming, folders, imports, error handling, tests).
 
 ## Output Format
@@ -71,7 +66,3 @@ Always return a structured summary — omit sections with no findings:
 ```
 
 Be concise within each section. Bullet points preferred over prose. Include `file:line` references wherever possible.
-
-## Cost Tier
-
-**CHEAP** — preferred for wide traversal that would pollute the orchestrator's context window. Do not spawn for tasks the orchestrator can answer with a single file read.

package/skills/subagent-execution/agents/planner.md

@@ -26,8 +26,8 @@ For LARGE tasks (cross-cutting, unclear scope, multiple subsystems), `/discovery
 
 ## Task Size Classification
 
-- **Large (3+ files OR any architectural change)**: ask up to 3 impact-prioritized clarifying questions in one message, then delegate to `explorer`/`researcher`, then produce the full plan with ADR.
-- **Small (1–2 files, no architectural impact)**: skip questions, delegate immediately, produce the plan, list assumptions at the end.
+- **Large** (the brief says MEDIUM or LARGE, or the work crosses module boundaries or changes architecture): ask up to 3 impact-prioritized clarifying questions in one message, then delegate to `explorer`/`researcher`, then produce the full plan with ADR.
+- **Small** (the brief says SMALL — isolated, clear requirements): skip questions, delegate immediately, produce the plan, list assumptions at the end.
 
 If findings reveal a "small" task is actually large, upgrade to the Large format retroactively.
 
@@ -97,7 +97,3 @@ Exact paths affected. Tree format if relevant.
 - **Tight scope** — never propose refactoring unrelated code.
 - Show trade-off reasoning in the ADR — don't just assert conclusions.
 - If a plan needs information you cannot obtain (e.g. missing business requirements), state it in a **Blockers** section rather than guessing.
-
-## Cost Tier
-
-**EXPENSIVE** — produces high-context output that informs all downstream work. Only spawn for tasks that genuinely need architectural thinking; small well-defined tasks don't need a dedicated planner agent.

package/skills/subagent-execution/agents/researcher.md

@@ -2,20 +2,14 @@
 name: "researcher"
 description: "Use this agent when any external library or framework API needs to be looked up before implementation. Invoke proactively whenever code will use a third-party dependency, an unfamiliar API method, or when exact parameter signatures, return types, or version-specific behavior must be confirmed. Fire non-blocking — delegate and continue working while it runs.\n\n<example>\nContext: The user is asking to implement a feature using a library API.\nuser: \"Add debounced search using lodash to the search input component\"\nassistant: \"Before implementing, let me use the researcher agent to look up the exact lodash debounce API.\"\n<commentary>\nSince the implementation requires a specific lodash API, delegate to researcher to get accurate reference before writing any code.\n</commentary>\n</example>"
 tools: CronCreate, CronDelete, CronList, EnterWorktree, ExitWorktree, ListMcpResourcesTool, LSP, Monitor, PushNotification, Read, ReadMcpResourceTool, RemoteTrigger, Skill, TaskCreate, TaskGet, TaskList, TaskStop, TaskUpdate, ToolSearch, WebFetch, WebSearch, mcp__plugin_context7_context7__query-docs, mcp__plugin_context7_context7__resolve-library-id
-model: sonnet
+model: opus
 color: blue
 memory: user
 ---
 
 You are a library and framework research specialist. You find accurate, version-specific API references before implementation. You never recall API details from memory — you verify from authoritative sources, and if none confirms a detail you omit it and say so rather than fabricate.
 
-## Delegation Pattern
-
-You are designed for **non-blocking delegation**:
-
-1. Orchestrator spawns you with a clear question
-2. Orchestrator continues implementing other tasks while you run
-3. Orchestrator retrieves your result when it's needed on the critical path
+## Scope
 
 Return a dense, actionable summary — not a tutorial.
 
@@ -71,8 +65,4 @@ Always return a reference card in this exact structure:
 - **Scope**: research only what was asked; don't expand into related APIs.
 - **Ambiguity**: if the package is ambiguous (multiple npm names), ask which is intended before researching.
 - **Failure**: if the chain is exhausted, return a card with Source Used: "Not found" and what was tried.
-- **No codebase reads** — you only look outward; never touch project files.
-
-## Cost Tier
-
-**CHEAP** — good for focused lookups. Don't spawn for things easily answered by reading the project's existing `package.json` or `AGENTS.md`.
+- **Outward-facing** — read only what version resolution needs (`package.json`, the lockfile, and the installed package under `node_modules`); don't read application source, and never edit project files.

package/skills/subagent-execution/references/install-codex-agents.mjs

@@ -19,7 +19,8 @@
 //   - tuning keys on an existing TOML (model, model_reasoning_effort,
 //     sandbox_mode, nickname_candidates) are preserved; otherwise
 //     sandbox_mode defaults to read-only for explorer/researcher and
-//     workspace-write for planner/coder
+//     workspace-write for planner/coder, and model / model_reasoning_effort
+//     default per MODEL_DEFAULTS (Free/Go plans get Luna only — edit down)
 //   - existing files are backed up to <name>.toml.bak first
 //
 // --uninstall removes exactly the .toml files this installer would have
@@ -31,7 +32,7 @@
 // [features] hooks flag is shared host state this script does not own.
 //
 // Schema per https://developers.openai.com/codex/subagents (verified
-// 2026-07-08): required name/description/developer_instructions; a custom
+// 2026-07-08; model / model_reasoning_effort keys re-verified 2026-10-04): required name/description/developer_instructions; a custom
 // agent named like a built-in (e.g. explorer) takes precedence over it.
 
 import fs from 'node:fs';
@@ -53,7 +54,15 @@ const SANDBOX_DEFAULTS = {
   planner: 'workspace-write',
   coder: 'workspace-write',
 };
-const PRESERVE_KEYS = ['model', 'model_reasoning_effort', 'sandbox_mode', 'nickname_candidates'];
+// Model tiers per spawn-rules.md → Codex Model Defaults. Applied per key,
+// only when the existing TOML doesn't set it.
+const MODEL_DEFAULTS = {
+  explorer: { model: 'gpt-6-luna', model_reasoning_effort: 'low' },
+  researcher: { model: 'gpt-6-astra', model_reasoning_effort: 'high' },
+  planner: { model: 'gpt-6.1-sol', model_reasoning_effort: 'medium' },
+  coder: { model: 'gpt-6.1-sol', model_reasoning_effort: 'medium' },
+};
+const PRESERVE_KEYS =['model', 'model_reasoning_effort', 'sandbox_mode', 'nickname_candidates'];
 
 function fmField(block, key) {
   const m = block.match(new RegExp('^' + key + ':[ \\t]*(.*)$', 'm'));
@@ -111,6 +120,9 @@ for (const file of fs.readdirSync(AGENTS_DIR).filter((f) => f.endsWith('.md')))
   if (!preserved.some((l) => l.startsWith('sandbox_mode')) && SANDBOX_DEFAULTS[name]) {
     preserved.push(`sandbox_mode = "${SANDBOX_DEFAULTS[name]}"`);
   }
+  for (const [key, value] of Object.entries(MODEL_DEFAULTS[name] || {})) {
+    if (!preserved.some((l) => l.startsWith(key + ' ') || l.startsWith(key + '='))) preserved.push(`${key} = "${value}"`);
+  }
 
   const toml = [
     `name = "${name}"`,

package/skills/subagent-execution/references/spawn-rules.md

@@ -7,9 +7,13 @@ Reference for deciding when and which agent to spawn. Read this before every spa
 | Tier          | Examples                  | Model                                  | When to Use                                                                                 |
 | ------------- | ------------------------- | ----------------------------------------- | --------------------------------------------------------------------------------------------- |
 | **FREE**      | —                         | n/a                                        | Built-in tool calls (bash, grep, file reads) — do these yourself, no agent needed           |
-| **CHEAP**     | `explorer`, `researcher`  | haiku                                      | Read-only, narrow scope, clear output. Good for lookup tasks that would bloat your context  |
+| **CHEAP**     | `explorer`                | sonnet, `effort: low`                      | Read-only, narrow scope, clear output. Good for lookup tasks that would bloat your context  |
+| **EXPENSIVE** | `researcher`              | opus                                       | Read-only, but source judgment decides the result — conflicting docs, version drift         |
 | **EXPENSIVE** | `coder`, `planner`        | sonnet (default) — see Model Selection     | Write-capable or high-context output. Justify carefully                                     |
 
+No agent uses haiku. Sonnet at low effort beats it at the same job in fewer
+turns, and turn count costs more than token price on multi-step work.
+
 ### Model Selection for `coder` Dispatch
 
 `coder`'s baseline model is sonnet. Override per-dispatch based on task
@@ -17,17 +21,33 @@ complexity — always pass the model explicitly; an omitted model silently
 inherits the session's own model, which is often the most capable and most
 expensive tier.
 
-| Task complexity                                                     | Model  |
-| --------------------------------------------------------------------- | ------ |
-| Mechanical, 1-2 files, complete spec/code already in the task brief    | haiku  |
-| Multi-file integration, pattern-matching, moderate judgment            | sonnet |
-| Architecture-level judgment; the final whole-branch review            | opus   |
-
-Turn count costs more than token price on multi-step work — the cheapest
-tier routinely takes more turns to reach the same result, which can cost
-more overall. Use sonnet as the floor for reviewers and for implementers
-working from prose descriptions; reserve haiku for tasks whose brief
-already contains the exact code to write.
+| Task complexity                                                     | Model                  |
+| --------------------------------------------------------------------- | ---------------------- |
+| Mechanical, 1-2 files, complete spec/code already in the task brief    | sonnet, `effort: low`  |
+| Multi-file integration, pattern-matching, moderate judgment            | sonnet                 |
+| Architecture-level judgment; the final whole-branch review            | fable → opus fallback  |
+
+**Fable is a dispatch-time choice, never a frontmatter pin.** It ships only
+on the Max plan, and Claude Code has no automatic fallback — a `fable`
+dispatch on a plan without it, or past Max's Fable allowance, errors or
+bills usage credits instead of downgrading. Dispatch `fable` only when the
+session is known to have it; if the dispatch fails on model availability,
+redispatch the same brief with `opus`. When unsure, use `opus`.
+
+### Codex Model Defaults
+
+`install-codex-agents.mjs` writes these when a TOML has no `model` /
+`model_reasoning_effort` of its own (yours always win):
+
+| Agent                | `model`        | `model_reasoning_effort` |
+| -------------------- | -------------- | ------------------------ |
+| `explorer`           | `gpt-6-luna`   | `low`                    |
+| `planner`, `coder`   | `gpt-6.1-sol`  | `medium`                 |
+| `researcher`         | `gpt-6-astra`  | `high`                   |
+
+Free and Go plans get Luna only, and Astra's plan gating is not settled in
+OpenAI's docs — on those plans, edit the TOML's `model` down. Codex has no
+documented fallback for an unavailable model either.
 
 ## Agent Capability Boundaries
 

package/skills/workflow/SKILL.md

@@ -231,8 +231,8 @@ with an injected prompt. Implement yourself by default; spawn only with concrete
 justification (unfamiliar codebase, external API to verify, genuinely parallel
 exploration, or a LARGE plan via `subagent-execution`).
 
-- `explorer` — read-only codebase navigation (haiku, non-blocking; LSP over grep).
-- `researcher` — external API/library verification (sonnet, non-blocking; resolves
+- `explorer` — read-only codebase navigation (sonnet at low effort, non-blocking; LSP over grep).
+- `researcher` — external API/library verification (opus, non-blocking; resolves
   the installed version first, omits what it can't verify).
 - `planner` — design → executable plan (sonnet; always delegates to explorer, and
   researcher when external libs are involved, before planning).