jorgex-stack 1.9.23 → 1.9.24

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jorgex-stack",
-  "version": "1.9.23",
+  "version": "1.9.24",
   "description": "Harness multi-agente portable: instala la config JorgeX (agentes, skills, hooks, Engram, MCPs) en Claude Code, Codex CLI, OpenCode y Pi",
   "type": "module",
   "license": "MIT",

package/stack/agents/code-simplifier.md

@@ -71,6 +71,8 @@ Your process:
 
 For each suggestion provide: file path and line, what to simplify and why, and a before/after snippet when useful. Prefix each lean finding with the matching `lean-code` tag (for example `shrink:` or `delete:`).
 
+Identify candidates for the `orchestrator` skill's **Substantial simplifications** gate. Explain the structural or cognitive complexity removed, why behavior is preserved, and any scope or verification risks. Do not classify a substantial improvement as optional merely because there is no functional bug. The coordinator validates the finding and its disposition; you remain read-only and do not defer work to backlog yourself.
+
 End lean-heavy reports with `net: -<N> lines possible` when you can estimate it. If nothing meaningful can be simplified, say so briefly. Your goal is to surface refinements that meet the highest standards of elegance and maintainability while preserving complete functionality — the implementer applies them.
 
 ## Types of refinement to propose

package/stack/skills/orchestrator/SKILL.md

@@ -84,13 +84,23 @@ Do not launch `code-reviewer`, `code-simplifier`, `test-analyzer`, or `silent-fa
 Both routes cap a failing task or criterion at three attempts. After the third failure, stop retrying, save the meaningful failure and what was tried through the required outcome or memory path, then re-plan with a different approach or report the blocker; never loop blindly.
 
 The three attempts do not reset by renaming tasks, replacing agents or redelegating the same unresolved criterion. Group accepted fixes by contract and cause. Before a second repair round after the initial review, if blockers persist or fixes introduce regressions, reassess the root cause, scope, owner and testing seam instead of automatically repeating the cycle. Do not automatically launch another review panel. Keep new valid bugs in triage; a rework limit never authorizes ignoring blockers or declaring success. Re-plan within approved scope with a concrete changed approach, or escalate a material scope decision. Keep the reason and useful outcome in the existing checkpoint, not a new budget ledger.
+### Substantial simplifications
+
+A substantial simplification demonstrably removes significant structural or cognitive complexity: unnecessary layers, duplicated flows, or hard-to-follow control paths become materially simpler to understand and maintain. Judge the before/after evidence, not line count or style preferences. The coordinator validates the evidence, behavior preservation, approved scope and risk; a reviewer's label alone is not acceptance.
+
+Validated substantial simplifications within approved scope are required work: implement and verify them before ready or closure, even when there is no functional bug. Do not downgrade them to optional suggestions or defer them to backlog unilaterally. Reuse the owning task and the applicable testing and review-revalidation rules; do not create another review panel by default.
+
+If a candidate requires expanded scope, has unverified behavior preservation or unresolved risk, raise an explicit user decision before implementing it or closing the affected work. Keep the unresolved gate visible; never expand scope or weaken safeguards to satisfy it. Deferring a validated substantial simplification requires explicit user approval, recorded with the reason in the existing task or checkpoint before using the existing backlog. Reject false positives with evidence instead of backlogging them.
+
+Optional minor or cosmetic suggestions remain non-blocking; closure does not require zero suggestions. The simplifier stays read-only and proposes changes for the implementer. A standalone read-only audit reports candidates but does not authorize implementation. This rule does not add review triggers or reset the bounded-retry limit.
+
 ### Final review and PR lifecycle
 
 The review boundary is the final candidate SHA while the PR is still draft, immediately before `gh pr ready`. It is one final review, not a mandatory panel or multiple reviewers for short work. Load and run the portable `xreview` skill when its scoped review adds value and reliable coverage is missing; pass the exact active `work/{name}` to every review subagent, never another work folder. Freeze base/head and merge-base, assign primary responsibility plus necessary support, and preserve each specialist's output contract.
 
 Use the [coverage revalidation rule](../xreview/SKILL.md#7-revalidate-coverage-and-stop): fix-check for a finding, delta-review for affected risks, full review when reliable coverage must be established or broadly rebuilt. A material change requires reassessing coverage, not automatically rerunning the same panel. Previously clean roles reopen when their contracts, dependencies or assumptions change; commits and readiness alone do not trigger reviewers. Record the scope and justification for retained evidence in the existing checkpoint, including changes to base or integration context even when head is unchanged.
 
-Triage valid findings before work/backlog creation, reconcile duplicates and reject false positives with reasons. New valid findings are not discarded for being new. Close when blocking findings and material uncertainty are resolved, fixes verified and current coverage justified, not when there are zero suggestions; the bounded-retry guard still applies.
+Triage valid findings before work/backlog creation, reconcile duplicates and reject false positives with reasons. Apply the [substantial simplifications](#substantial-simplifications) gate before treating improvements as optional or deferring them. New valid findings are not discarded for being new. Close when blocking findings and material uncertainty are resolved, fixes verified and current coverage justified, not when there are zero suggestions; the bounded-retry guard still applies.
 
 Both routes keep the PR draft while it changes, use the canonical Git worktree, complete review before ready, wait for configured gates, compare the candidate SHA before reporting or merging, and never merge without explicit user approval.
 

package/stack/skills/orchestrator/references/standard-workflow.md

@@ -158,7 +158,7 @@ An early review during EXECUTE is an **exception**, not a default phase. Use it
 When the current checkpoint's planned work is applied and VERIFY passes:
 
 1. Confirm the draft PR exists, the worktree is clean, and the draft head matches the local HEAD. Complete any necessary documentation under the common rule and inspect the consolidated final diff against the PR's real base; do not publish intermediate behavior with required documentation missing.
-2. Apply **Final review and PR lifecycle** in the entry [SKILL.md](../SKILL.md) and the project's review requirements. Reuse valid prior review evidence; choosing standard does not require another panel. Process the review findings by their three levels:
+2. Apply **Final review and PR lifecycle** in the entry [SKILL.md](../SKILL.md) and the project's review requirements. Reuse valid prior review evidence; choosing standard does not require another panel. Apply the [substantial simplifications gate](../SKILL.md#substantial-simplifications) first: required simplifications are not discretionary improvements or nice-to-have suggestions. Process the remaining review findings by their three levels:
    - **Critical Issues (must fix)**: apply ALL of them — the PR must not reach merge with these open.
    - **Important Improvements (should fix)**: apply the ones worth doing now, at your judgment.
    - **Suggestions (nice to have)**: apply only if trivial and safe.

package/stack/skills/xreview/SKILL.md

@@ -88,10 +88,11 @@ If none of a subagent's triggers are present, skip it and note that it was skipp
 
 After the relevant subagents complete, synthesize their findings into a unified report. Use 4R internally (Reliability / Resilience / Readability / Risk) as a checklist while synthesizing; do not add a separate 4R section or taxonomy to the final report.
 
-Reconcile duplicates and verify disputed premises before creating work. Distinguish a missed bug, a regression introduced by a fix and an optional suggestion. A new valid finding still needs triage; being new is not a reason to discard it. Record justified rejection of false positives, not backlog entries for them. Only valid work deliberately deferred belongs in the existing backlog, using its single-writer protocol.
+Reconcile duplicates and verify disputed premises before creating work. Distinguish a missed bug, a regression introduced by a fix and an optional suggestion. Apply the orchestrator's [substantial simplifications gate](../orchestrator/SKILL.md#substantial-simplifications): report validated substantial simplifications as required before ready or closure, even without a functional bug, not as nice-to-have suggestions. This classification does not authorize a read-only reviewer to edit code. A new valid finding still needs triage; being new is not a reason to discard it. Record justified rejection of false positives, not backlog entries for them. Only valid work deliberately deferred belongs in the existing backlog, using its single-writer protocol and the gate's approval requirement.
 
 - Review scope used (BASE/HEAD or working diff) and how it was chosen
 - Subagents run vs skipped (with reason)
+- Substantial Simplifications (required before ready/closure unless explicitly deferred by the user); the following three levels cover the remaining findings
 - Critical Issues (must fix)
 - Important Improvements (should fix)
 - Suggestions (nice to have)