jorgex-stack 1.9.72 → 1.9.74

package/stack/skills/diagnose/SKILL.md

@@ -23,7 +23,7 @@ Spend disproportionate effort here. **Be aggressive. Be creative. Refuse to give
 
 ### Ways to construct one — try them in roughly this order
 
-Inspect the project's existing runner, fixtures, helpers and diagnostic commands first. Reuse the closest suitable harness; the options below are not an instruction to build a second testing stack. Apply `lean-code`'s diagnostic tooling policy before adding or retaining tooling.
+Inspect the project's existing runner, fixtures, helpers and diagnostic commands first. Reuse the closest suitable harness; the options below are not an instruction to build a second testing stack. Apply [Lean Code's diagnostic tooling policy](../lean-code/SKILL.md#diagnostic-tooling) before adding or retaining tooling.
 
 1. **Failing test** at whatever seam reaches the bug — unit, integration, e2e.
 2. **Curl / HTTP script** against a running dev server.

package/stack/skills/lean-code/SKILL.md

@@ -62,7 +62,7 @@ Prefer the narrowest change that solves the real need.
 
 ### Diagnostic tooling
 
-Reuse the project's runner, fixtures, helpers and existing diagnostic commands before building a harness. New probes, replay scripts and diagnostic harnesses are temporary by default, with explicit resource ownership and automatic teardown arranged before execution. Keep tooling only for a concrete recurring need: identify its consumer, why the existing harness cannot cover it, and who maintains it in the current task or PR. A successful one-off investigation alone does not justify a permanent command, framework or dependency. Preserve the authoritative regression test and compact reproduction evidence, not the disposable environment.
+Reuse the project's runner, fixtures, helpers and existing diagnostic commands before building a harness. New probes, replay scripts and diagnostic harnesses are temporary by default, with explicit resource ownership and automatic teardown arranged before execution. Keep tooling only for a concrete recurring need within the approved scope: identify its consumer, why the existing harness cannot cover it, and who maintains it in the current task or PR. Seek approval if retaining it expands the scope. A successful one-off investigation alone does not justify a permanent command, framework or dependency. Preserve the authoritative regression test and compact reproduction evidence, not the disposable environment; do not remove meaningful permission, concurrency or deletion protection just to shrink the diff.
 
 ### Review / simplification
 

package/stack/skills/to-prd/SKILL.md

@@ -29,7 +29,7 @@ The solution to the problem, from the user's perspective.
 
 ## User Stories
 
-A LONG, numbered list of user stories. Each user story should be in the format of:
+A numbered list of user stories proportional to the approved scope. Each user story should be in the format of:
 
 1. As an <actor>, I want a <feature>, so that <benefit>
 
@@ -37,7 +37,7 @@ A LONG, numbered list of user stories. Each user story should be in the format o
 1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending
 </user-story-example>
 
-This list of user stories should be extremely extensive and cover all aspects of the feature.
+Include only the actors, behaviors and relevant boundary cases supported by the context. Do not invent speculative requirements or pad the list to meet a length target. A small feature may need only one story.
 
 ## Clarifications
 

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

@@ -33,7 +33,7 @@ Check:
 3. Every SC is verifiable and has task coverage in the plan table.
 4. Every formal task resolves and verifies its declared `Spec` reference, task identity and access before execution. An identity mismatch, missing source or absent access is a blocking `gaps` verdict; never reconstruct a missing spec from the PRD.
 5. Every task references known SCs and has one agent, one bounded scope, affected files, dependencies and a wave consistent with those dependencies.
-6. Each behavior-changing task has a complete testing decision: risk, existing protection, new behavior, chosen seam and action.
+6. Each behavior-changing task has a complete testing decision: risk, existing protection, new behavior, chosen seam and action. Apply the testing value check below to the proposed protection.
 7. PR scopes, bases and ordering are compatible with the task dependencies.
 8. PRD, plan and task specs do not contradict each other or duplicate status/evidence into a second home.
 
@@ -53,7 +53,7 @@ Check:
 3. Every in-scope SC has concrete evidence in its canonical checkpoint: command/setup, scope, result and relevant limits.
 4. The implementation diff and observed behavior stay within the approved PRD, plan and task scopes.
    - POST cannot legitimize scope changes retroactively. For intentional material contract changes, send scope drift to SPEC through change-first. Defects or bugfixes restoring the approved contract return to EXECUTE.
-5. Tests, typecheck/build, manual checks and external gates are not over-claimed; missing or incomplete execution remains explicit.
+5. Tests, typecheck/build, manual checks and external gates are not over-claimed; missing or incomplete execution remains explicit. Apply the testing value check below to the implemented protection and actual evidence.
 6. No accepted requirement, edge case, testing decision, documentation change or cross-repo contract assigned to the current checkpoint is left without implementation or evidence. Future checkpoints remain out of scope.
 
 POST verdicts:
@@ -61,6 +61,16 @@ POST verdicts:
 - `converged` — the available evidence satisfies the approved contract. This does not replace tests, human review, configured Quality Gates or manual validation when applicable.
 - `gaps` — return actionable findings to the orchestrator and route each to its owning phase; never send every gap unconditionally to EXECUTE. Rerun POST after the fix.
 
+## Testing value check — PRE and POST
+
+For each added or strengthened test, ask: "What concrete regression does this test detect that existing coverage does not?" PRE checks the proposed answer; POST checks that the actual assertions and evidence support it. Another layer must protect a distinct contract, not repeat the same behavior.
+
+For a mechanical test update, `reuse` or `no new test`, check the identified existing protection or other verification and why it is sufficient. Do not demand a new test, extra coverage or a manufactured RED when the risk is already covered.
+
+A RED for behavioral protection must fail because the asserted behavior is wrong or missing, not merely because a source string is absent. Structural assertions are valid when structure is itself the contract, such as triggers, permissions, secret handling or suite registration; distinguish that guarantee from runtime behavior and avoid freezing an incidental command recipe, internal ordering or full implementation.
+
+Keep this check within the checkpoint's changed behavior and relevant coverage; do not turn it into a suite-wide audit.
+
 ## Read-only boundary
 
 - Do not write, edit or modify the PRD, plan, task specs, memory, code, tests, checkboxes or PR state.

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

@@ -76,7 +76,8 @@ Every formal task has exactly one recoverable `Spec` reference in the plan table
 | 03 | 02 | [agent] | [bounded scope] | [one declared source] | [descriptive name] | [one-line description] | SC-01 | ⬜ | 2 | 01 |
 | 04 | 02 | [agent] | [bounded scope] | [one declared source] | [descriptive name] | [one-line description] | SC-02 | ⬜ | 2 | 01, 02 |
 
-**Statuses**: ⬜ Pending → 🔴 RED → 🟢 GREEN → 🔍 Review → ✅ Done
+**Statuses**: ⬜ Pending → In progress → Verified → 🔍 Review → ✅ Done
+For test-first work that adds or strengthens protection, use 🔴 RED → 🟢 GREEN within In progress. Tasks using `reuse` or `no new test` proceed with their chosen verification; do not require a new failing test to advance.
 ```
 
 ---
@@ -111,7 +112,7 @@ Use this adaptable content in the one source declared by the plan's `Spec` colum
 - **Existing protection**: [specific existing test/evidence, or none]
 - **New behavior**: [behavior needing new protection, or none]
 - **Chosen seam**: [closest authoritative seam and why]
-- **Action**: [add | update | reuse | no new test] — [concrete reason]
+- **Action**: [add | update | reuse | no new test] — [for new or stronger protection, the concrete regression existing coverage misses; for a mechanical test update, reuse or no new test, why existing protection or other verification is sufficient]
 ```
 
 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.
@@ -137,11 +138,11 @@ Mutation is serialized: the coordinator is the single writer, reads the exact ob
 
 ### Atomicity
 
-- **Max ~5 implementation steps** per task. If more → split into two tasks.
+- Bound each task by an independently verifiable behavior or contract and its concrete regression risk. Keep the layers needed for that outcome together; split when outcomes can be verified independently or coupling and risk warrant it, not at a fixed step count.
 
 ### Structure
 
-- **Natural order**: data layer → generated types → services/hooks → components/UI.
+- **Vertical slices**: organize tasks by behavior and risk, not by technical layer. Sequence implementation within a task by its real dependencies; data, types, services and UI are not mandatory separate tasks.
 - **Numbering**: `01`, `02`, `03`... (two digits) — shared by the plan table row and the topic_key.
 
 ### Context
@@ -154,7 +155,7 @@ Mutation is serialized: the coordinator is the single writer, reads the exact ob
 
 - **VERIFIABLE**: "the type includes X", not "the type is correct".
 - **SPECIFIC**: no copy-paste of generic criteria.
-- **COMPLETE**: cover happy path, edge cases and errors.
+- **COMPLETE**: cover the relevant happy path, boundary cases and errors for the approved contract and concrete risk; do not manufacture speculative scenarios.
 
 ### Constraints