@dzhechkov/keysarium 1.5.28 → 1.5.30

package/README.md

@@ -29,6 +29,7 @@ After installation, open Claude Code in your project directory and start using s
 | Component | Count | Description |
 |-----------|-------|-------------|
 | **Skills** | 12 | `explore`, `frontend-design`, `goap-research-ed25519`, `presentation-storyteller`, `problem-solver-enhanced`, `reverse-engineering-unicorn`, `knowledge-extractor`, `ai-factory-mapper`, `analyst-manual-full`, `edu-site-generator`, `transcript-site-generator`, `feature-adr` |
+| | | *bundled `feature-adr` at pipeline v1.3.60: amendment-Confirmation discipline (AM-N → named falsifying test), derived `🚦 Gates` checkpoint line, opt-in Step-10 Delivery Gate (4-plane post-implementation review)* |
 | **Commands** | 20 | `/casarium`, `/new-research`, `/parallel-research`, `/discovery`, `/explore-case`, `/research`, `/cjm-prototype`, `/solve`, `/architecture-phase`, `/presentation`, `/harvest`, `/brain-export`, `/brain-import`, `/bto-benchmark`, `/feature-adr`, `/init-platform`, `/learning-stats`, `/dream`, `/workers`, `/analyst-manual` |
 | **Rules** | 14 | `research-quality`, `checkpoint-protocol`, `agent-swarm`, `domain-specific`, `anti-patterns`, `file-conventions`, `modular-reuse`, `feedback-loops`, `model-routing`, `trust-tiers`, `background-workers`, `dream-cycles`, `reward-learning`, `feature-adr-conventions` |
 | **Shards** | 9 | Context shards for each phase: `phase-0-discovery`, `phase-1-explore`, `phase-2-research`, `phase-25-cjm`, `phase-3-solve`, `phase-4-architecture`, `phase-5-presentation`, `phase-ai-factory`, `feature-adr` |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dzhechkov/keysarium",
-  "version": "1.5.28",
+  "version": "1.5.30",
   "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

@@ -53,7 +53,8 @@ Trigger on:
 │   ├── 06-implementation-plan.md      ← Step 6: SPARC-GOAP planning (enhanced)
 │   ├── 07-code.md                     ← Step 7: Code generation
 │   ├── 08-qe.md                       ← Step 8: QE + brutal-honesty review (enhanced)
-│   └── 09-fleet-qe.md                 ← Step 9: Fleet QE assessment (NEW)
+│   ├── 09-fleet-qe.md                 ← Step 9: Fleet QE assessment (NEW)
+│   └── 10-delivery-gate.md            ← Step 10: Delivery Gate (opt-in, post-implementation)
 ├── references/
 │   ├── complexity-matrix.md           ← S/M/L/XL criteria & step activation
 │   ├── adr-template.md                ← ADR document template
@@ -140,6 +141,7 @@ Step                         | S | M | L | XL | Model  | Agentic QE Skill
 7  Code                      | ✓ | ✓ | ✓ | ✓  | opus   | —                      |
 8  QE + Brutal Honesty       | ✓ | ✓ | ✓ | ✓  | sonnet | brutal-honesty-review  |
 9  Fleet QE Assessment       | - | - | ✓ | ✓  | sonnet | qe-req-val + risk-based + integration + regression + coverage |
+10 Delivery Gate (OPT-IN)    | o | o | o | o  | cross-family of coder | 4 planes: regressions ‖ security ‖ code-quality ‖ product-honesty (o = runs only when explicitly requested; absent ⇒ byte-identical) |
 ```
 
 ## DAG Dependencies
@@ -271,6 +273,7 @@ features/<feature-slug>/
 | Step 7 | `<promise>FEATURE_ADR_IMPLEMENTED</promise>` |
 | Step 8 | `<promise>FEATURE_ADR_VERIFIED</promise>` |
 | Step 9 | `<promise>FEATURE_ADR_FLEET_VERIFIED</promise>` |
+| Step 10 (opt-in) | `<promise>FEATURE_ADR_DELIVERY_GATED</promise>` |
 
 ## External Skills (loaded as needed)
 
@@ -493,6 +496,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 +592,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 — · delivery n/a
 
 [2-3 line summary]
 Artifacts: [list] ✅
@@ -592,3 +602,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:

package/templates/.claude/skills/feature-adr/modules/10-delivery-gate.md

@@ -0,0 +1,63 @@
+# Step 10: Delivery Gate (opt-in) — review the feature as a PUBLISHED ENTITY
+
+> **Opt-in.** This step runs only when explicitly requested (the user asks for a delivery gate, or the
+> workflow form receives `args.deliveryGate: true` / `args.models.delivery`). Absent ⇒ the pipeline is
+> byte-identical to a run without Step 10 — no agents, no artifact.
+
+## Why a separate step (not more Step-8)
+
+Step 8 reviews the code as the coder's counterpart — pre-hand-off, working-tree view. Step 10 reviews the
+feature as a **published entity**: the landed diff, its docs and claims, its behavior as a consumer will
+meet it. Its distinctive plane — **product honesty** — is absent from Step 8 entirely: fabricated
+completeness (output presented as complete when a source was unavailable), a feature that does less than
+its description, misleading user-facing text. Origin: a real incident where a 2-agent fresh-eyes pass said
+SHIP and only the full multi-plane review found the fabricated-completeness and cap-violation defects.
+
+## Protocol
+
+### 1. Four orthogonal planes (parallel, cross-family of the coder)
+
+Each plane reads `07_code_changes/change_manifest.md` + the actual changed files (+ `git diff` for anything
+uncommitted), calibrating on `architecture/vision.md` / `architecture/degradations.md` **when present** (an
+accepted degradation is NOT a finding) and staying generic when absent:
+
+| Plane | Hunts |
+|---|---|
+| **Regressions** | broken consumers/contracts; NEW I/O on previously-pure startup/lifespan/health paths without a negative resource-down test; removed/weakened tests (fixture-swap); silent semantic changes to shared surfaces |
+| **Security** | injection via interpolated paths/refs/commands; secrets in code/artifacts; path traversal/symlink escapes; fail-open where the contract says fail-closed |
+| **Code quality** | god-object growth; parallel implementations vs the reuse map; structurally-dead safeguards; swallowed errors |
+| **Product honesty + common sense** | claims not backed by behavior; fabricated completeness; docs/READMEs promising more than the code does; misleading degradation/limits text |
+
+Findings shape: `{severity: BLOCKER|HIGH|MED|LOW, title, where (file:line), why}` — confirmed only.
+
+### 2. Cross-validation (BLOCKER/HIGH, by index)
+
+Every BLOCKER/HIGH is independently cross-validated by a second agent, matched **positionally by index —
+never by title** (duplicate titles cross-contaminate). Default-to-FP when uncertain. A validator outage
+surfaces the findings **UNVALIDATED** — never silently dropped, never silently confirmed.
+
+### 3. Machine-checkable hand-off criterion
+
+Write `features/<slug>/10_delivery_review.md`:
+- **## Verdict** — `hand-off: ready | blocked` (ready ⇔ 0 BLOCKER and 0 unwaived HIGH, cross-validation complete)
+- **## Findings** — table: severity | plane | title | where | why | crossValidated
+- **## Hand-off criterion** — machine-checkable rows: `0 BLOCKER: PASS/FAIL(n)`, `0 unwaived HIGH: PASS/FAIL(n)`.
+  Projects with a merge-request flow add THEIR OWN rows here (`CI terminal: …`, `draft→ready: …`) — these are
+  **document rows the owner fills**, never API calls made by the pipeline. No merge-request flow ⇒ the rows
+  stay `—`.
+- **## Note** — ADVISORY: the owner decides; nothing auto-aborts.
+
+### Hard rules
+
+1. **Findings only.** Step 10 NEVER posts to a VCS host, tracker, or any external service. Publishing a
+   review anywhere is a separate, explicit user instruction.
+2. **Advisory.** `hand-off: blocked` is a report, not an abort (a false gate kills trust).
+3. **Cross-family.** The planes run on the other model family than the coder (the Step-8 rule) — a model
+   must not deliver-gate its own code.
+4. **Cost control.** One gate per hand-off, not per commit. A stack of related changes gets one Step-10 pass
+   on the combined diff.
+
+## Promise tag
+
+`<promise>FEATURE_ADR_DELIVERY_GATED</promise>` — and the `🚦 Gates:` line gains `delivery ready|blocked`
+(derived from the review doc's Verdict, `n/a` when the gate was not requested).