jorgex-stack 1.0.29 → 1.0.31

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

@@ -146,6 +146,16 @@ Status, wave and dependencies live in the plan.md table (single home) — do NOT
 
 - [Rule]
 
+## Testing decision
+
+- **Risk**: [meaningful regression this task can introduce]
+- **Existing protection**: [specific existing test/evidence, or none]
+- **New behavior**: [behavior needing new protection, or none]
+- **Chosen seam**: [unit/component/database/integration/contract/e2e and why it is closest to the risk]
+- **Action**: [add | update | reuse | no new test] — [concrete reason]
+
+Prefer one authoritative test per behavior. Another layer is justified only when it protects a distinct contract. Styling, wiring, generated code, mechanical refactors, and trivial changes may use `no new test`; business rules, bugs/regressions, public contracts, and invariants should normally use TDD.
+
 ## Acceptance criteria
 
 [VERIFIABLE and SPECIFIC criteria — not generic. Each must be checkable manually or automatically.]

package/stack/system-prompt/AGENTS.md

@@ -110,9 +110,11 @@ Every piece of information about a piece of work has exactly ONE home — never
 
 ## Testing and Verification
 
-- When the project has tests or the change affects behavior, testing is mandatory.
-- For new features, bug fixes, or behavior changes, use TDD when it fits.
-- Use the `tdd` skill for red-green-refactor, test-first work, or integration-style behavior testing.
+- When the project has tests or the change affects behavior, verification is mandatory. A new test is not.
+- Make one explicit testing decision per change: what risk it introduces, what existing test already covers it, what new behavior needs protection, and why no new test is needed when the change is trivial, mechanical, or already covered.
+- Use TDD for business rules, bugs/regressions, public contracts, and invariants. Do not impose it on styling, wiring, generated code, mechanical refactors, or trivial code unless they change meaningful behavior.
+- Prefer one authoritative test at the strongest seam closest to the risk. Add coverage at another layer only when it protects a distinct contract, not to repeat the same behavior.
+- Use the `tdd` skill for red-green-refactor, test-first work, or risk-based behavior testing.
 - Prefer targeted verification before broad suites.
 - Default order: specific test > partial suite > full suite.
 - Use the real test commands and test stack of the project.

package/upstreams.json

@@ -74,7 +74,8 @@
     "tdd": {
       "source": "github:mattpocock/skills",
       "path": "skills/engineering/tdd",
-      "commit": "694fa30311e02c2639942308513555e61ee84a6f"
+      "commit": "694fa30311e02c2639942308513555e61ee84a6f",
+      "modified": true
     },
     "to-issues": {
       "source": "github:mattpocock/skills",

package/stack/modes/programmatic/agent-delegation.addendum.md

@@ -1,11 +0,0 @@
-<!-- jorgex:programmatic-mode -->
-## Programmatic Mode
-
-- Use English only.
-- Keep replies compact and direct.
-- Delegations must be strings in the final JSON `delegations[]` array, using `agent: work — paths — inputs`.
-- Do not emit Markdown delegation lines.
-- Use the strict final JSON handoff.
-- `delegations[]` is only for work that belongs to another specialist; uncertainty questions go in `summary` or `risks`, not in `delegations[]`.
-- If task-critical uncertainty could make the task wrong, set `status` to `blocked` and include one concrete question to the main agent/orchestrator, with what you checked and the decision needed.
-- If the safe path is clear, do the safe part and report the remainder as `partial`.