@jabworks/condux 0.4.0 → 0.4.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jabworks/condux",
-  "version": "0.4.0",
+  "version": "0.4.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/finalize/SKILL.md

@@ -110,9 +110,9 @@ Tests      ✓ 18 passed
 
 ## Companion Files
 
-One cheap scan of the diff, reported alongside the gate. It never blocks —
-it exists because "remember to update the env example for newly added env vars"
-should not have to be said again.
+One cheap scan of the diff, reported alongside the gate. It never blocks — it
+exists because a new env var that never reaches the example file is invisible
+until it breaks someone else's checkout.
 
 - A new env var anywhere in the diff (`process.env.X`, `import.meta.env.X`, a
   new key in an env schema, a new `docker-compose`/CI variable) ⇒ the project's

package/skills/live-verification/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: live-verification
-description: "Verify a change by actually running it — drive the real UI or endpoint, check each claim against observed behaviour, and capture evidence before pushing. Detects what's runnable, verifies dark mode first, and reports claim → evidence → verdict with unverifiable claims named rather than hidden. After /finalize, before committing or pushing a change that has a runnable surface — UI, page, component, endpoint, CLI. Triggers include \"verify it live\", \"did this actually work\", \"check it in the browser\", \"live verify before pushing\", \"does it render right\". Not for typecheck/lint/test (that's finalize), not for auditing plan completeness (preflight), not for reading code to judge it (code-review)."
+description: "Verify a change by actually running it — drive the real UI or endpoint, check each claim against observed behaviour, and capture evidence before pushing. Detects what's runnable, checks light mode then dark, and reports claim → evidence → verdict with unverifiable claims named rather than hidden. After /finalize, before committing or pushing a change that has a runnable surface — UI, page, component, endpoint, CLI. Triggers include \"verify it live\", \"did this actually work\", \"check it in the browser\", \"live verify before pushing\", \"does it render right\". Not for typecheck/lint/test (that's finalize), not for auditing plan completeness (preflight), not for reading code to judge it (code-review)."
 argument-hint: "[what to verify — optional; defaults to the current diff]"
 ---
 
@@ -62,8 +62,8 @@ honestly: report what could not be driven rather than inventing a result.
 
 Order of checks, because this is where the defects were:
 
-1. **Dark mode first.** Then light. A themed change is not verified until it
-   has been seen in both.
+1. **Light mode first.** Then dark. A themed change is not verified until it
+   has been seen in both — that part is the gate, not the order.
 2. **The interactive states**, not just the resting one — hover, focus,
    disabled, selected, and the in-flight state of every mutation.
 3. **The failure path.** Make the thing fail on purpose if you can (offline,
@@ -116,7 +116,7 @@ Two failed attempts on the same claim is the ceiling. Report and move on.
 ## Live verification: <change>
 
 Target     http://localhost:3000 (pnpm dev — started by this run)
-Themes     dark ✓  light ✓
+Themes     light ✓  dark ✓
 
 Claim                                          Evidence            Verdict
 Save disabled while mutation in flight         save-pending.png    ✓