lazycodex-ai 5.1.5 → 5.1.6

package/packages/prompts-core/prompts/ultrawork/codex.md

@@ -286,17 +286,17 @@ Until every success criterion PASSES with its evidence captured:
    vars. Append a one-line cleanup receipt to the notepad next to the
    artifact, e.g. `cleanup: killed 12345; tmux kill-session ulw-qa-foo;
    rm -rf /tmp/ulw.aB12cD`. No receipt → criterion stays in_progress.
-6. Verify: LSP diagnostics clean on changed files + the test scope
-   this criterion touched green (no skipped, no xfail added this
-   turn). Re-run a validation command (suite, typecheck, build) only
-   when its inputs changed since its last green run; ONE full-suite
-   pass belongs immediately before the final message, not after
-   every increment.
+6. Verify: LSP diagnostics clean on changed files; no test skipped or
+   xfail-ed this turn.
 7. Mark completed. Append non-obvious findings / learnings.
-8. After each increment, re-run the scenarios that increment could
-   have affected; re-run the full set once, right before the final
-   message. Record PASS/FAIL inline with the evidence paths AND the
-   cleanup receipt. Loop until all PASS.
+8. Evidence stays valid per target until an input changes; record with
+   each artifact the commit and what it exercised. After each increment
+   rerun what moved — the tests of every touched file and of the files
+   that import it, the scenarios that exercise them, anything whose
+   dependencies or environment changed — and cite the capture for the
+   rest. The full set (scenarios, suite, typecheck, build) runs once
+   more right before the final message. Record PASS/FAIL beside each
+   artifact. Loop until all PASS.
 
 Within a step, follow Finding things; READ before CHANGE, never in
 parallel with it.
@@ -399,13 +399,12 @@ When triggered, follow this procedure (NON-NEGOTIABLE):
    it names a success criterion the evidence fails; record concerns
    that cite no criterion as notes with a one-line reason — fixed or
    declined at your judgment.
-3. Fix every criterion-cited blocker. Re-run ONLY the scenario QA
-   affected by the fix; capture fresh evidence for the delta. Update
-   notepad.
-4. Re-submit to the SAME reviewer at most twice, passing only the
-   delta diff, the blockers it cited, and the already-approved criteria
-   marked out-of-scope. An approval whose only remaining items are
-   notes counts as approval.
+3. Fix every criterion-cited blocker; rerun per Execution loop step 8
+   and update the notepad.
+4. Spawn a NEW reviewer for each re-review, at most twice, passing only
+   the delta diff, the blockers the last one cited, and the
+   already-approved criteria marked out-of-scope. An approval whose only
+   remaining items are notes counts as approval.
 5. On approval, declare done. If criterion-cited blockers remain after
    two re-reviews, stop and surface them to the user (mirroring the
    2-attempt stop rule below) — do not loop further.
@@ -430,7 +429,15 @@ commits this session — then stage + draft the message instead.
   for the regression it names is NOT evidence: mock-call assertions,
   pinned constants, a fixture equal to the default it must override,
   an expected value re-derived from the output under test.
-- Smallest correct change. No drive-by refactors.
+- Make the smallest correct change per unit, and fix in THIS run every
+  defect inside the change's blast radius — the request not delivered,
+  a regression this change introduces, an invalid proof, a failing test
+  or stale doc of code you touched — as registered work (todo plus
+  success criterion) to the ideal state. A defect outside it gets a
+  tracked issue with reproduction and evidence and a line in the final
+  message; a deferral never turns a criterion into PASS. Keep delegated
+  unit scope hard: the worker reports, the orchestrator registers or
+  files.
 - Never suppress lints / errors / test failures. Never delete, skip,
   `.only`, `.skip`, `xfail`, or comment out tests to green the suite.
 - Never claim done from inference — only from captured evidence.

package/packages/shared-skills/skills/browser/runtime/omowright/manifest.json

@@ -5,5 +5,5 @@
     "index.js": "b6b064fab277031c6c51f5a58b84b31040f9960bf767bf646adc0540c1d25c1b",
     "page-bundle.js": "bfd51e8383cf47200d57387bbbed258bce5a3a3d00c38fc108034d2888e23f0c"
   },
-  "stagedAtUtc": "2026-09-30T10:38:45.312Z"
+  "stagedAtUtc": "2026-09-30T18:48:33.732Z"
 }

package/packages/shared-skills/skills/ulw-execute/SKILL.md

@@ -53,7 +53,7 @@ Do ALL of this immediately after the plan is selected, BEFORE the first implemen
 
 1. **Set the goal, in detail.** When a goal tool is available (`create_goal`), call it with a DETAILED objective: the plan name and path, the concrete end state, the phase and task counts, the delivery mode (direct, `--make-pr`, or `--ship`), and how completion will be verified. One work session = one registered goal (the goal tool holds one active goal); each phase then carries its own concrete goal — the ledger entry Phase 2 records before the wave's first dispatch, defined from the previous phase's landed and verified evidence. No goal tool -> record the same objective as the first ledger entry.
 2. **Register every phase and task as todos.** Mirror the plan into the todo/plan tool of your harness: one phase per plan wave, one todo per column-zero checkbox (including the final verification wave). Register ALL of them up front - never keep tasks in memory only.
-3. **Keep them current at every moment.** Mark a todo in_progress when its work dispatches and done immediately after its verification passes. Never batch-complete at the end, never execute work that is not a registered todo; discovered work — a pre-existing bug, failing test, stale doc, or wrong guidance — is appended to the plan as a checkbox, mirrored as a todo before it runs, and fixed to the ideal state, never deferred as a follow-up. A worker that meets a defect outside its assigned files reports it instead of fixing it; only the orchestrator appends the checkbox and dispatches it to a correctly scoped unit. The todo list, Boulder state, and plan checkboxes must always tell the same story.
+3. **Keep them current at every moment.** Mark a todo in_progress when its work dispatches and done immediately after its verification passes. Never batch-complete at the end, never execute work that is not a registered todo; discovered work inside the change's blast radius — the request not delivered, a regression this change introduces, an invalid proof, a failing test or stale doc of touched code — is appended to the plan as a checkbox, mirrored as a todo before it runs, and fixed to the ideal state; a defect outside it gets a tracked issue with reproduction and evidence and a line in the final report. A worker that meets a defect outside its assigned files reports it instead of fixing it; only the orchestrator appends the checkbox and dispatches it to a correctly scoped unit. The todo list, Boulder state, and plan checkboxes must always tell the same story.
 
 ## Phase 1: Select the plan