@brainervirus/workit-codex 8.19.0 → 8.19.1

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "workit",
-  "version": "8.19.0",
+  "version": "8.19.1",
   "description": "Adaptive engineering workflow rails for Codex",
   "author": {
     "name": "BrainerVirus"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@brainervirus/workit-codex",
-  "version": "8.19.0",
+  "version": "8.19.1",
   "private": false,
   "description": "Workit Codex CLI/desktop plugin — shared MCP transport, hooks, method skills, and verifier/reviewer/implementer agents",
   "keywords": [
@@ -39,8 +39,8 @@
     "build": "bun scripts/build.ts"
   },
   "devDependencies": {
-    "@brainervirus/workit-core": "^8.19.0",
-    "@brainervirus/workit-mcp": "^8.19.0"
+    "@brainervirus/workit-core": "^8.19.1",
+    "@brainervirus/workit-mcp": "^8.19.1"
   },
   "engines": {
     "node": ">=24"

package/skills/workit-implement/SKILL.md

@@ -24,7 +24,10 @@ description: Build a requested change in small verified steps - follow local pat
    lease waits and names its holder (`workit lock status`).
 5. Prove the feature on its real surface with the project's `verify-<app>`
    skill; none yet? Write one (read the `workit-verify-app` skill's SKILL.md and follow it). Tests show branch behavior,
-   not that the feature works.
+   not that the feature works. The report carries what you observed: a UI
+   change a screenshot or console/network check (chrome devtools or
+   agent-browser), an API a quoted real response. App not runnable? Say so
+   plainly, never claim success.
 6. Commit: `workit git commit -m "<type>: <what>" -- <paths>` (or `--all`).
    No endpoint named? Stop here and state the next command. Hand delivery to
    ship, which pushes and opens the PR with its body shape (read the `workit-ship` skill's SKILL.md and follow it), only
@@ -55,8 +58,7 @@ flag was never invoked)
 
 Good: "Added `--since`. measured: `workit check test` exit 0;
 `mytool log --since 2d` printed 3 entries against the fixture repo. inferred:
-the GitLab path behaves the same (shared parser, not run). Verification handed
-to the verifier agent."
+the GitLab path behaves the same (not run). Handed to the verifier agent."
 
 ## Check
 

package/skills/workit-verify-app/SKILL.md

@@ -27,7 +27,10 @@ way a user would.
    - **Drive:** how to exercise it: CLI invocations, `curl` against routes, a
      browser tool for UI, with fixture data.
    - **Evidence:** what to capture (exit code, response body, screenshot path)
-     and the command that records it.
+     and the command that records it. A UI is driven with chrome devtools or
+     agent-browser, with a screenshot or console/network observation; an API
+     with a real call, response quoted. The report carries the observation.
+     App not runnable? Say so plainly, never claim success.
    - **Cleanup:** stop processes, remove temp data.
    - **Feature map:** feature, how to drive it, expected observation.
 3. **Prove it end-to-end once:** launch, drive one feature, capture evidence,
@@ -54,7 +57,8 @@ report `clean`, `changed` (what) or `blocked` (why).
 Bad: "Verify by running the tests." (that is not the real surface)
 
 Good: "Launch `bun run dev` (ready: `listening on :5173`, 30 s). Drive:
-`curl -s localhost:5173/api/health` returns `{"ok":true}`. Evidence:
+`curl -s localhost:5173/api/health` returned `{"ok":true}`; screenshot of
+/settings at .workit-scratch/settings.png. Evidence:
 `workit check --name verify-web -- bun scripts/smoke.ts` exit 0."
 
 ## Check

package/skills/workit-verify-app/references/template.md

@@ -30,6 +30,8 @@ description: Launch, drive and observe <app> on its real surface (<cli|web|api>)
 ## Evidence
 `workit check --name verify-<app> -- <driver command>` records exit code and log.
 Screenshots go to `<tmp dir>/verify-<app>/<feature>.png`; cite the path.
+UI: also report a console or network observation. API: quote the real response.
+If the app cannot be run, say so plainly instead of claiming success.
 
 ## Cleanup
 `<command>` (stop servers, remove `<tmp dir>`).