jorgex-stack 1.9.13 → 1.9.14

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jorgex-stack",
-  "version": "1.9.13",
+  "version": "1.9.14",
   "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/modes/programmatic/orchestrator.addendum.md

@@ -12,6 +12,7 @@
 - `status` is one of `done`, `partial`, `blocked` and `decision` is a short string.
 - `confidence` is a number between 0 and 1.
 - `summary` is a short string.
+- For a PR-ready handoff, use the existing text fields for its metadata, concise changes and observed workflow feedback; keep current limitations in `risks` and pending actions in `next_steps`. Do not add JSON keys or a new `ready` status. A ready PR does not mean the whole assigned work is done when later checkpoints remain.
 - `risks`, `next_steps`, and `delegations` are arrays of strings.
 
 {{CONCURRENCY_RULE}}

package/stack/skills/orchestrator/SKILL.md

@@ -82,6 +82,14 @@ Triage valid findings before work/backlog creation, reconcile duplicates and rej
 
 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.
 
+### Ready handoff
+
+At each verified ready checkpoint, preserve the existing PR metadata (URL/number, candidate SHA, checks and relevant base/dependencies) and briefly summarize the concrete changes and result, not merely the file list. Usually two to four short bullets plus one feedback line are enough. State what worked and any material friction, retries or remaining limitation actually observed; do not invent a balanced story, savings or problems when there were none.
+
+Use the work already performed and its existing evidence/checkpoint; do not launch another agent or investigation just to write the summary. Ready is not merged, deployed or the end of a multi-PR roadmap. Report the actual next action or dependency without granting merge permission or inventing a pause requirement.
+
+Respect the active output contract. In programmatic mode, keep the strict final JSON and its existing keys/types: put changes and factual workflow feedback in `summary`, current limitations in `risks` and pending actions in `next_steps`, preserving PR metadata in allowed text fields. Do not add keys, a `ready` status value, Markdown fences or prose outside that final JSON. Intermediate progress uses the permitted channel rather than pretending to be another final response.
+
 ## Closing rule
 
 Do not declare work finished after analysis or planning alone: complete the routed execution or report the concrete blocker.

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

@@ -170,7 +170,7 @@ When the plan is fully applied and VERIFY passes:
 
 ## 8. CLOSE
 
-- STOP here and hand control back to the user only after configured Quality Gates pass for the latest commit, or after confirming that the project has no PR checks configured: report the candidate SHA, check result or confirmed absence, review findings applied vs deferred to `work/backlog`, and whether manual testing is advisable (recommend it for big or user-facing changes; small well-tested changes may not need it).
+- STOP here and hand control back to the user only after configured Quality Gates pass for the latest commit, or after confirming that the project has no PR checks configured. Apply the common [Ready handoff](../SKILL.md#ready-handoff): preserve the PR metadata, summarize changes and observed workflow feedback, report valid findings applied vs deferred and whether manual testing is advisable. Do not claim merge, deployment or overall roadmap completion from a ready checkpoint.
 - NEVER merge the PR yourself — merge only on an explicit user order. After each intermediate merge: persist the checkpoint to `work/{name}/pr/{NN}`, update `plan.md`, and keep `work/{name}/` alive. After the final merge: persist the final outcome to memory, clean up `work/{name}/` and remove the worktree (see Work state).
 - If the repo has its own skill for the closing steps (release, deploy, git, cleanup), that skill takes precedence over the default behavior.