@jabworks/condux 0.25.2 → 0.26.1

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.25.2",
+  "version": "0.26.1",
   "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/finalize/SKILL.md

@@ -77,7 +77,7 @@ Tests fail
 
 ## Output Format
 
-The `Plan` line below only appears when no matching plan doc was found for the inferred feature slug — it's omitted entirely otherwise.
+The `Plan` line below only appears when no matching plan doc was found for the inferred feature slug — it's omitted entirely otherwise. In a mobile app project a `Native` line joins `Env` (see Companion Files); the example below is a web project, so it has none.
 
 ```
 ## Finalize: [task or feature name]
@@ -119,6 +119,13 @@ until it breaks someone else's checkout.
   example file (`.env.example`, `.env.sample`, or whatever it uses) gains the
   same key in the same change — placeholder value only, never a real secret.
 - Report `Env  ✓ n/a` when the diff adds none, so the check is visibly running.
+- **Native (mobile app projects only).** None of the gates above compiles the
+  native layer, so a diff that touches it passes everything and still is not
+  in the app until it is rebuilt and reinstalled. Classify the diff as
+  `JS only` or `native rebuild` and report it as a `Native` line; on a native
+  rebuild, end "Ready to commit — native rebuild needed before it can run" and
+  name the project's rebuild command. The path list, the fingerprint check and
+  when to omit the line are in `references/native-change.md`.
 
 ## What Does NOT Happen
 
@@ -134,3 +141,4 @@ until it breaks someone else's checkout.
 ## See Also
 
 - `references/rationalization-table.md` — common rationalizations for skipping finalize and why they're wrong
+- `references/native-change.md` — mobile apps: when a diff needs a native rebuild, the fingerprint check, the `Native` line

package/skills/finalize/references/native-change.md

@@ -0,0 +1,106 @@
+# Native-change check
+
+A mobile app has two layers. JavaScript reloads in seconds; the native binary
+(Kotlin/Swift, native modules, the compiled app config) only changes when the
+app is **rebuilt and reinstalled**. None of the JS gates — typecheck, lint,
+format, tests — compile the native layer, so a change that touches it can pass
+every gate and still not exist in the app on the device. This check makes that
+visible. It never blocks.
+
+Its verdict is used in three places: finalize reports it, workflow mentions it
+at tier confirmation, and live-verification acts on it before driving the app.
+
+## When it applies
+
+Only in an app project: an `expo` or `react-native` dependency in
+`package.json`, or a committed `android/` or `ios/` directory. Anywhere else,
+omit the `Native` line entirely — a web repo gets no noise from it.
+
+## The verdict
+
+Two outcomes. Name the escalation, lightest first:
+
+| Verdict | Means | To see the change |
+|---|---|---|
+| **JS only** | Nothing in the diff reaches the binary | Fast Refresh or a JS reload; restart the app process if a native module is left in a bad state |
+| **Native rebuild** | The diff touches something compiled into the binary | Rebuild the app (dev client or release build) and reinstall it; clear the app's data too when the change touches native state that persists across installs (notification channels, permissions, keychain entries, database schema created natively) |
+
+## How to decide
+
+**Precise — when a recorded fingerprint exists.** Expo projects can hash
+their native layer. If `.condux/native/fingerprint-<platform>.json` exists
+(recorded after the last native build — see below), generate a fresh one the
+same way and compare the two JSONs' `hash` fields:
+
+```bash
+# with expo-updates installed — per platform, the same hash EAS uses:
+npx expo-updates fingerprint:generate --platform android > .condux/native/now-android.json
+# without it — covers both platforms at once:
+npx @expo/fingerprint fingerprint:generate > .condux/native/now-all.json
+```
+
+Equal hashes are **JS only**. Different hashes are **Native rebuild** — then
+name what moved with
+`npx @expo/fingerprint fingerprint:diff <recorded> <now>`. The `now-*` file is
+overwritten on every check. Compare against the recording for the platform
+you are building; a both-platforms fingerprint also moves on iOS-only changes,
+so say which one you used. The fingerprint covers what a path list cannot
+see — autolinked native modules inside `node_modules`, config-plugin output,
+patches to native packages.
+
+**Core — always available.** Otherwise, read the task's diff. Any of these
+means **Native rebuild**:
+
+- local native code: `modules/**` (Expo modules), any `.kt`, `.java`, `.swift`,
+  `.m`, `.mm`, `.cpp`, `.h` file, `*.podspec`, `build.gradle*`
+- committed native projects: `android/**`, `ios/**` (if they are generated by
+  prebuild, the real change is upstream of them — find it)
+- app config compiled into the binary: in `app.json` / `app.config.*`, the
+  `plugins`, `permissions`, `android`/`ios` blocks, `name`, `scheme`, `version`,
+  `runtimeVersion`, splash and icon assets; any config-plugin source file
+- dependencies: a package added, removed or version-changed in `package.json`
+  that ships native code (it has an `android/` or `ios/` directory, or an
+  `expo-module.config.json`), and every Expo SDK or React Native upgrade
+- patches: `patches/**` touching a native package, `cng-patches/**`
+- `eas.json` build-profile changes that alter what is compiled
+
+When a file's effect is unclear, say **Native rebuild** and name the file —
+a wasted rebuild costs minutes; a verification against a stale binary costs
+the whole verification.
+
+**Project override.** If `AGENTS.md` lists the project's native paths or its
+rebuild command, those win over the lists above.
+
+## Recording the fingerprint
+
+The precise check needs a baseline, so whoever rebuilds and installs the app
+records one straight after the install succeeds:
+
+```bash
+mkdir -p .condux/native
+npx expo-updates fingerprint:generate --platform android > .condux/native/fingerprint-android.json
+# or, without expo-updates:
+npx @expo/fingerprint fingerprint:generate > .condux/native/fingerprint-all.json
+```
+
+It lives in `.condux/` (working state, gitignored) because it describes the
+build installed on *this* machine's device or emulator, not the repository.
+Only Expo projects record one — the fingerprint reads the Expo config, and
+`npx` fetches the tool if it isn't installed. Bare React Native and native-only
+projects use the core check alone.
+
+## Reporting
+
+In finalize's output, beside `Env`:
+
+```
+Native     ✓ JS only (android fingerprint unchanged) — a reload shows it
+Native     ⚠ native rebuild — modules/app-lock/android/…/AppLockModule.kt, app.json plugins
+             not compiled by any gate; rebuild with `npx expo run:android` and reinstall before verifying
+```
+
+Take the rebuild command from `AGENTS.md` or `package.json` scripts; if
+neither names one, say "rebuild the app" and stop — never guess a build
+command. On **Native rebuild**, finalize ends "Ready to commit — native rebuild
+needed before it can run": the code is clean; the app just does not contain it
+yet.

package/skills/live-verification/SKILL.md

@@ -43,6 +43,15 @@ Do not assume a dev server. In order:
 Start it in the background, wait for it to actually serve (poll the URL — do
 not `sleep` and hope), and note the URL in the report.
 
+**Mobile app: rebuild first when the change is native.** If finalize's
+`Native` line said *native rebuild* (or the diff touches the native layer —
+see finalize's native-change check), the installed app does not contain the
+change. Rebuild and reinstall it before driving anything, and clear the app's
+data when the change touches native state that persists across installs. On
+an Expo project, record the new fingerprint as that check describes. A verdict
+driven on the old binary is a verdict on code that isn't there — if the
+rebuild can't run here, stop and report that instead.
+
 ### Step 2 — Enumerate the claims
 
 Before touching the UI, write down what the change claims to do — one line

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

@@ -9,13 +9,7 @@ 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 +19,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 +29,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 +65,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

@@ -9,13 +9,7 @@ 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/spawn-rules.md

@@ -7,7 +7,7 @@ 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`, `researcher`  | haiku (`explorer`), sonnet (`researcher`)  | Read-only, narrow scope, clear output. Good for lookup tasks that would bloat your context  |
 | **EXPENSIVE** | `coder`, `planner`        | sonnet (default) — see Model Selection     | Write-capable or high-context output. Justify carefully                                     |
 
 ### Model Selection for `coder` Dispatch

package/skills/workflow/SKILL.md

@@ -70,7 +70,11 @@ Every tier ends with `preflight` then `finalize` — no exceptions.
 ## The Router
 
 1. **Infer the tier.** How many files? Requirement clear or needs design? Crosses
-   service/package boundaries? Unknowns needing exploration first?
+   service/package boundaries? Unknowns needing exploration first? In a mobile
+   app, also: does it touch the native layer (finalize's native-change check
+   lists what does)? That doesn't change the tier — a one-line Kotlin fix is
+   still SMALL — but say so when confirming, because nothing can verify it
+   until the app is rebuilt and reinstalled.
 2. **Spec lookup.** Detect the package root (walk up from CWD to git root, find the
    nearest `package.json` / `Cargo.toml` / `go.mod` / `pyproject.toml`). Check both
    scopes (deduplicate if identical):