jorgex-stack 1.9.10 → 1.9.11

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jorgex-stack",
-  "version": "1.9.10",
+  "version": "1.9.11",
   "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/backend-analyst.md

@@ -42,9 +42,9 @@ Skills especially relevant to this role:
 
 ## Output format
 
-1. **Map**: services, tables and endpoints involved
-2. **Findings**: patterns, risks and debt (ordered by severity)
-3. **Recommendation**: proposed design for the change
+1. **Map**: affected services, tables, endpoints, consumers and boundaries, with precise file/symbol references for the decisive facts
+2. **Findings**: patterns, risks and debt (ordered by severity); distinguish observed facts from assumptions and identify uncertainties that could change the implementation
+3. **Recommendation**: the smallest compatible design and its tradeoffs; include alternatives only when they affect a decision the coordinator must close
 
 ## Result contract
 

package/stack/agents/frontend-analyst.md

@@ -32,9 +32,9 @@ Adapt to whatever the project uses (React, Vue, Svelte, etc.). Mirror existing c
 
 ## Output format
 
-1. **Map**: components, hooks, state and files involved
-2. **Findings**: existing patterns and risks (ordered by severity)
-3. **Recommendation**: proposed approach for the change
+1. **Map**: affected components, hooks, state, consumers and boundaries, with precise file/symbol references for the decisive facts
+2. **Findings**: existing patterns and risks (ordered by severity); distinguish observed facts from assumptions and identify uncertainties that could change the implementation
+3. **Recommendation**: the smallest compatible approach and its tradeoffs; include alternatives only when they affect a decision the coordinator must close
 
 ## Result contract
 

package/stack/skills/orchestrator/SKILL.md

@@ -27,6 +27,12 @@ For the **standard** route, explicitly read and follow [references/standard-work
 
 Both routes preserve mandatory memory/Engram saves, testing/TDD by risk, Git/worktree discipline, final-draft review, configured gates, and explicit user approval for merge. Security, permissions, ownership, backups, dependency consent, and the existing human/programmatic output contracts are never relaxed by routing. Product documentation remains with `docs-maintainer` when it is needed; short routing does not absorb that owner's scope.
 
+## Decision before delegation
+
+Use analysis only where it resolves an uncertainty that matters. An analyst's recommendation is evidence for the coordinator, not an implementation order: check the decisive sources, distinguish facts from assumptions, and close the scope, approach, relevant invariants and verification seam before delegating implementation. For formal work, record those decisions in its single Spec. Do not repeat the whole investigation or copy its report into the task.
+
+Keep tightly coupled critical reasoning or execution with the primary when explaining it would duplicate most of the work; otherwise delegate a bounded outcome with the closed decisions and concrete escalation conditions. Preserve specialist ownership and the existing autonomy to resolve routine details: do not require consultation for every edit. If a material decision cannot be closed, resolve or escalate it rather than hiding it in an implementation task.
+
 ## Work state
 
 The `work-lifecycle` skill is the single source for **formal SDD** work. Each formal task has one recoverable Spec source and one plan row. A direct or inline message is an auxiliary microassignment under a parent task, never a formal or independent task or a second Spec; if it grows into independent work, persist its formal task spec and plan row before continuing. Pass a delegated worker the exact Spec as read-only. Its distinct outcome topic_key must never overwrite that Spec; significant decisions and findings still require immediate memory saves, and checkpoint outcomes persist as required. Do not write memory for a poll or status without new information.
@@ -41,6 +47,8 @@ Load the `agent-delegation` skill: it defines the available subagents, their sco
 
 Both routes follow the project Git/worktree rules; short is not an exception. Where those rules explicitly permit a trivial direct-main change, keep that exception; otherwise resolve the root with `git rev-parse --show-toplevel`, ensure `worktrees/` is ignored in the repo-local `.git/info/exclude`, and create/use `<project-root>/worktrees/<canonical-name>` or `<project-root>/worktrees/<canonical-name>-prNN` with the branch matching the worktree name.
 
+Keep one concrete objective per PR: a verifiable vertical slice bounded by contract, coupling and risk. When assessing size, distinguish behavior (including prompts and configuration), tests/fixtures, documentation and generated files; do not ignore any category or split necessary tests away from their change just to reduce a line count. Split at independently verifiable contracts when the combined risk or review burden warrants it, not at a fixed number of added lines.
+
 After the first coherent commit, push the work branch and open the PR with `gh pr create --draft`. Keep it draft while it changes. Mark it ready once with `gh pr ready <number>`. If the project has PR checks configured, wait for Quality Gates, run `gh pr checks <number>`, and verify they pass for the latest commit candidate. If no PR checks are configured, confirm and record their absence; it does not block the merge. An empty `gh pr checks` result immediately after ready is not evidence that no checks are configured. Immediately before reporting or merging, compare `gh pr view --json headRefOid` with the recorded candidate SHA. If a ready PR needs a fix, run `gh pr ready --undo <number>` before editing, then repeat verification, review, ready, and configured gates.
 
 After each intermediate merge: persist the checkpoint to `work/{name}/pr/{NN}`, update `plan.md`, and keep `work/{name}/` alive. Merge always requires explicit user approval.
@@ -66,4 +74,4 @@ Both routes keep the PR draft while it changes, use the canonical Git worktree,
 
 ## Closing rule
 
-Do not declare work finished after analysis or planning alone: complete the routed execution or report the concrete blocker.
+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

@@ -20,7 +20,7 @@ The human drives the flow UP TO the plan: the idea, the PRD review and the plan
 
 ## 2. EXPLORE
 
-Launch analysts according to scope:
+Follow [Decision before delegation](../SKILL.md#decision-before-delegation): reuse verified context and involve an analyst only where material uncertainty needs new evidence. Choose the specialist for that question, rather than launching one merely because an area is touched:
 
 - `backend-analyst` if it affects backend, DB, APIs or server functions
 - `frontend-analyst` if it affects UI, hooks, state or rendering
@@ -83,7 +83,7 @@ Commit after each task or bounded group of tasks, with a message that reflects t
 
 ### Handoff rule
 
-The analyst's **Recommendation** is the implementer's input. Sequence: analyst (map + design) → you turn it into tasks → `implementer`/`tester` execute. Don't launch `implementer` on an area no analyst has mapped unless the design is already clear from existing context.
+Follow the common [Decision before delegation](../SKILL.md#decision-before-delegation) rule: analysis where needed → coordinator closes the material decisions → one Spec → execution by the appropriate owner. A recommendation does not bypass the coordinator's decision, and an already-understood area does not require another analyst pass.
 
 ### Testing decision
 
@@ -186,4 +186,4 @@ A task must correspond to a single agent and a single scope. Don't mix productio
 
 ## Closing rule
 
-Don't declare the task finished if you have only analyzed or planned. There must be real execution by the subagents or a concrete blocker.
+Don't declare the task finished if you have only analyzed or planned. There must be real execution by the subagents or a concrete blocker.

package/stack/skills/work-lifecycle/SKILL.md

@@ -50,7 +50,7 @@ Use this section only after routing selects formal SDD work, including work prom
 
 ## Pull request lifecycle
 
-1. Start from the updated production branch in the canonical worktree/branch. Keep one concrete objective per PR.
+1. Start from the updated production branch in the canonical worktree/branch. Apply the shared PR-scope rule in [Worktree and PR lifecycle](../orchestrator/SKILL.md#worktree-and-pr-lifecycle); formal SDD does not define a separate size policy.
 2. Implement one coherent first slice, commit it, push the work branch, and open the PR immediately as draft with `gh pr create --draft`.
 3. Continue implementation, commits and pushes only while the PR is draft. Draft means the code can still change; ready means the current SHA is the candidate to merge.
 4. Before ready, complete every applicable preflight item: code, version bump, local tests, project quality command (`pnpm qa:quality` when defined), Vercel preview review when the project uses Vercel, final diff inspection, and full PR review.

package/stack/skills/work-lifecycle/references/plan-template.md

@@ -94,7 +94,7 @@ Use this adaptable content in the one source declared by the plan's `Spec` colum
 
 ## decisive context
 
-[Only the decisions, verified facts and precise references the worker needs. Include a fragment only when it clarifies the contract.]
+[Only the closed decisions, verified facts and precise references the worker needs, not the full investigation. Distinguish facts from assumptions or unresolved questions that could change the task. When relevant to a decision, identify the source and whether a state is current, proposed or conditional on a later event. Include a fragment only when it clarifies the contract.]
 
 ## contract and invariants
 
@@ -102,7 +102,7 @@ Use this adaptable content in the one source declared by the plan's `Spec` colum
 
 ## validation and escalation
 
-[Verification that demonstrates completion. Escalate a material uncertainty, missing source access or identity mismatch instead of reconstructing the spec from the PRD.]
+[Verification that demonstrates completion and the concrete conditions requiring escalation. Escalate a material uncertainty, missing source access or identity mismatch instead of reconstructing the spec from the PRD; routine implementation details do not require repeated permission.]
 
 ## Testing decision
 
@@ -114,6 +114,8 @@ Use this adaptable content in the one source declared by the plan's `Spec` colum
 ```
 
 Use only the headings and fields that are pertinent, except retain the complete testing decision when the task changes behavior. Do not require literal code, input/output blocks or empty heading, section or field. Existing Engram task observations remain compatible; adapt this template only for newly created or materially revised specs.
+
+Delimit paths and commands clearly, preserving spaces and flags. Shortening a handoff must not concatenate a path with its access mode or erase distinctions needed to execute it safely.
 ---
 
 ## Backlog entry — Template (`work/backlog`)