@dzhechkov/keysarium 1.5.28 → 1.5.29

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dzhechkov/keysarium",
-  "version": "1.5.28",
+  "version": "1.5.29",
   "description": "AI Case Research Toolkit for Claude Code — full 7-phase pipeline with feature-adr, dream cycles, background workers, multi-platform support, reward learning, and Cloud.ru AI Factory mapping (--ai-factory flag)",
   "main": "src/cli.js",
   "bin": {
@@ -50,4 +50,4 @@
   "publishConfig": {
     "access": "public"
   }
-}
+}

package/templates/.claude/skills/feature-adr/SKILL.md

@@ -493,6 +493,12 @@ only the statusline:
 🎓 Learning: {recalled} patterns recalled for this feature, {stored} new stored this run
 ```
 
+**Record the panel at the START of every step, not only at Steps 0/8/9.** The panel shows the last step
+that reported; a pipeline that reports three times per run shows a stale step for most of its life. Emit
+`dz statusline --fa-record --slug <slug> --step "<Step N Name>" --recalled <n> --stored <n>` as the first
+action of each step. The recall/teach counts only change at Steps 0/8/9; the *step label* changes at every
+one of them.
+
 *Honesty note:* the panel is live only insofar as the pipeline records state — it reflects what the
 pipeline actually did with the loop (recalls that ran, stores that landed), not an aspirational count.
 
@@ -583,6 +589,7 @@ npx @dzhechkov/skills-feature-adr init --with-learning --knowledge-extractor
 <promise>[PROMISE_TAG]</promise>
 Tier: {COMPLEXITY_TIER} | Active Steps: {ACTIVE_STEPS}
 🎓 Learning: {recalled} patterns recalled for this feature, {stored} new stored this run
+🚦 Gates: challenge-panel ✓ · claim-check ✓ · discrimination not-run · amendments ✓ · fleet —
 
 [2-3 line summary]
 Artifacts: [list] ✅
@@ -592,3 +599,16 @@ Artifacts: [list] ✅
 • "[feedback]" — adjust
 ═══════════════════════════════════════════════════════
 ```
+
+### The 🚦 Gates line (mandatory, DERIVED — never asserted from memory)
+
+Every checkpoint banner carries a `🚦 Gates:` line listing each gate relevant to the run so far. Symbols:
+`✓` ran and passed · `✗` ran and failed · `not-run` pending · `—` N/A for this tier/slice (say why once).
+Each value is **derived from machine-checkable state** — an artifact's existence, a command's JSON verdict, a
+test result — never from what the orchestrator remembers doing. The line does not make a gate run; it makes
+NOT running one loud: a skipped gate shows as `not-run` by construction instead of being silently forgotten
+(cost-of-detection ladder: the banner is the one surface emitted at EVERY step boundary, so strapping the
+checklist to it is the cheapest way to harden orchestrator judgment). Gate sources: challenge-panel → its
+verdict exists; claim-check → its JSON counts (`high-findings` vs `clean`); discrimination → the
+`dz discrimination-check` aggregate; amendments → every `AM-N` row carries its `→ test` and it was checked;
+fleet → the 09 artifact (L/XL only, else `—`).

package/templates/.claude/skills/feature-adr/modules/03.5-ideation-swarm.md

@@ -119,7 +119,8 @@ After all agents complete, apply decision logic:
 | Critical Risks | > 2 | 1-2 | 0 |
 
 - **NO-GO**: BLOCK. Requirements/ADR need rework. Return to Step 1 or Step 3.
-- **CONDITIONAL**: Proceed with warnings. Pass findings to Steps 6-8 as advisory context.
+- **CONDITIONAL**: Proceed with warnings. Each condition becomes an **amendment row** in a `## Amendments`
+  section (see below) — not loose advisory prose.
 - **GO**: Full confidence. Proceed to Step 6.
 
 ### 5. Synthesis Report
@@ -132,6 +133,26 @@ Generate consolidated `03.5_ideation_report.md` with:
 5. Test ideas (categorized: unit / integration / E2E)
 6. Conditional agent findings (if any)
 7. Recommendations prioritized by risk × impact
+8. `## Amendments` — on a CONDITIONAL verdict, every condition as a fixed-shape row (see below)
+
+### Amendment Confirmation discipline (every amendment is a mini-ADR)
+
+Amendments are where the sharpest design corrections land — and, historically, the least-tested part of a
+run: they arrive as prose AFTER the ADR's Confirmation discipline already ran, so a coder can implement one
+with no test proving it works. Therefore every amendment carries a one-line **Confirmation**, in a fixed,
+machine-checkable shape:
+
+```
+AM-N (source): <change>. Confirmation: <property> → test `test_name` (fails if reverted).
+```
+
+- `source` names where it came from (qcsd | challenge-panel | user-steer).
+- The named test must FAIL if the amendment were reverted/broken (non-vacuous — Step 8 verifies via
+  `dz discrimination-check`).
+- For a **safeguard** amendment (a warning/guard/fallback): the test must prove the safeguard actually
+  **TRIGGERS on a real input** — not merely that its code path exists. A structurally-dead safeguard passes
+  an existence test and never fires in production.
+- A cheap lint holds the shape: every `AM-N` line must contain a `→ test ` token naming a test that exists.
 
 ## Output
 

package/templates/.claude/skills/feature-adr/modules/06-implementation-plan.md

@@ -149,6 +149,11 @@ Create `features/<slug>/06_implementation_plan.md` with:
 - Parallel groups
 - Checkpoint schedule
 - Risk assessment (L/XL)
+- `## Amendments` — every correction folded into this plan (a Step-3.5 CONDITIONAL condition, a
+  challenge-panel confirmed finding, a user checkpoint steer) as a fixed-shape row:
+  `AM-N (source): <change>. Confirmation: <property> → test `test_name` (fails if reverted).`
+  A safeguard amendment's named test must prove it TRIGGERS on a real input, not merely that its code
+  path exists. Step 8 verifies every named test exists and is non-vacuous (`dz discrimination-check`).
 
 Set `{IMPL_PLAN}` variable.
 
@@ -169,6 +174,21 @@ Estimated {K} files to create/modify
 ═══════════════════════════════════════════════════════
 ```
 
+## Challenge panel (adversarial plan-gate — before coding)
+
+Before leaving the plan checkpoint for code (especially L/XL), offer the **`challenge-panel`** skill — a
+FRESH adversary (never the plan author) tries to BREAK the plan across the fixed C1-C8 owner questions,
+every P0/P1 is cross-validated, and the verdict is ADVISORY (never an auto-block):
+
+```bash
+dz challenge --plan features/<slug>/06_implementation_plan.md --author <planner-model>
+```
+
+Dispatch the panel on the CROSS-FAMILY model (`--author` prints which): plan by Claude → Codex adversary
+(honest `codex exec`, never a stub); plan by Codex → fresh Claude. Drop any P0/P1 the cross-validator does
+not confirm. A finding the owner accepts can be recorded in `architecture/degradations.md` so C1 stops
+re-flagging it. In the ultracode workflow this врезка runs automatically and returns `challengeVerdict`.
+
 ## Quality Gates
 
 - [ ] Every task has clear done criteria

package/templates/.claude/skills/feature-adr/modules/07-code.md

@@ -31,6 +31,24 @@ Before writing any code:
 - [ ] Identify import patterns and module structure
 - [ ] Identify error handling patterns
 - [ ] Identify test patterns
+- [ ] Plan carries `## Amendments`? → implement every AM-N row AND its named Confirmation test (a
+      safeguard amendment needs a test proving it FIRES on a real input)
+- [ ] Does the diff add I/O (DB/network/file) to a previously-pure path — especially
+      startup/lifespan/health? → name the NEGATIVE resource-down test, or justify N/A
+
+### The I/O-on-pure-path rule (and the fixture-swap smell)
+
+If a change introduces I/O into a path that was previously I/O-free — above all a startup, lifespan, or
+health path — the happy-path test is NOT enough. Also write a **negative resource-down test**: a
+broken/unbound resource handle (dead DB, missing table, exhausted pool) → the path degrades per its
+declared contract — **fail-open** for an advisory feature, **explicit fail-fast** for a load-bearing one.
+Without it, an outage of the resource takes down the whole path (including health checks) for the sake of
+an advisory feature — and healthy test fixtures will hide it.
+
+**Fixture-swap smell:** if making the new code pass required replacing a "broken" test fixture with a
+healthy one — stop. The old fixture was probably a negative control proving the path was I/O-free. Keep
+BOTH tests: the healthy one (new behavior) and the broken one (degradation contract). Never silently
+delete the case that proved the old property.
 
 ### 2. Execute Tasks per Plan
 

package/templates/.claude/skills/feature-adr/modules/08-qe.md

@@ -158,6 +158,30 @@ Reject explainer-masquerading-as-ADR: if the document describes a problem space
 
 The Confirmation-to-test link is load-bearing. If absent, grade no better than C and record a blocker gap; for architecture dependency/layering/interface rules, recommend an ArchUnit or ArchUnitTS fitness function.
 
+### 3b. Amendment Gate (P2 — amendments inherit the Confirmation discipline)
+
+Read the `## Amendments` sections of `03.5_ideation_report.md` and `06_implementation_plan.md` (skip
+silently if absent). For EVERY `AM-N` row verify:
+1. the row contains a `→ test ` token naming a real test (the fixed shape);
+2. the named test **exists** in the suite;
+3. it is **non-vacuous** — include the amendment test files in the SAME
+   `dz discrimination-check --test <f1,f2,...> --base HEAD --json` run as the ADR property test. An
+   amendment test that stays green at pre-feature base proves nothing about its amendment;
+4. a **safeguard** amendment's test proves the safeguard FIRES on a real input (a structurally-dead
+   safeguard passes an existence test and never fires in production).
+
+A missing, unnamed, or vacuous amendment test is a HIGH gap. This closes the distance between "we caught
+the design flaw" (challenge-panel/QCSD) and "we proved the fix works".
+
+### 3c. I/O-on-pure-path + fixture-swap hunt (P5)
+
+In the TEST diff, hunt for replacements of broken/unbound fixtures with healthy ones — the old fixture was
+probably a **negative control** proving a path was I/O-free; each such swap requires a compensating
+negative resource-down test. In the CODE diff, hunt for new I/O (DB/network/file) on previously-pure
+paths — especially startup/lifespan/health: require a negative resource-down test (broken resource → the
+path degrades per its declared contract: fail-open for advisory, explicit fail-fast for load-bearing).
+Missing → HIGH gap.
+
 ### 4. Multi-Agent Review Panel (L/XL)
 
 For L/XL features, spawn 3 parallel review agents using brutal-honesty modes: