@antoneeo/kb-agentic-skill 1.4.4 → 1.4.6

package/CHANGELOG.md

@@ -2,6 +2,25 @@
 
 Every significant change to this skill is recorded here.
 
+## [1.4.6] - 2026-08-06
+
+### Changed
+- **Shared-spine sync: review-driven corrections + reviewer honesty (ACTIVE in this lens).**
+  The shared `review.md` gains the scoped re-review discipline — a fix made in response to a
+  finding is unreviewed work and gets a correction-scoped re-review with per-finding verdicts
+  before PASS — plus the `CANNOT VERIFY` reporting duty and the no-pre-judging rule. Unlike
+  prior spine syncs these are NOT inert here: reviews of knowledge artifacts inherit the
+  correction discipline directly.
+
+## [1.4.5] - 2026-08-06
+
+### Changed
+- **Shared-spine sync: Functional Spec clause (inert in this lens).** The shared
+  `review.md` gains the code lens's Functional Spec findings (absence on behavior change,
+  Solution-leakage inside the spec, uncovered cases, acceptance criteria without tests).
+  The kb lens defines no `## Functional Spec` template section, so the clause stays inert
+  here — spine parity only.
+
 ## [1.4.4] - 2026-08-05
 
 ### Changed

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "kb-agentic-skill",
-  "version": "1.4.4",
+  "version": "1.4.6",
   "description": "Knowledge-Base & Document-First protocol with risk triage, Vision governance, signal distillation and optional devPNT integration.",
   "author": "Antonio Pinto (https://github.com/Antoneeo)"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@antoneeo/kb-agentic-skill",
-  "version": "1.4.4",
+  "version": "1.4.6",
   "description": "Knowledge-Base & Document-First protocol for Claude Code, Gemini CLI, Google Antigravity and Codex with risk triage, Vision governance, signal distillation and optional devPNT integration.",
   "keywords": [
     "claude-code",

package/skills/kb-agentic-skill/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: kb-agentic
-version: 1.4.4
+version: 1.4.6
 description: Knowledge-Base & Document-First protocol with risk-proportional triage, Vision as a guide, Signal Distillation, a complete Standalone mode and optional symbiosis with devPNT. Use for user documentation, knowledge extraction, SOPs, research notes, decision logs and knowledge management.
 author: Antonio Pinto (https://github.com/Antoneeo)
 copyright: (c) 2026 Antonio Pinto

package/skills/kb-agentic-skill/review.md

@@ -99,6 +99,12 @@ conversation instead of reviewing the change itself. Say which finding
 classes you want covered (correctness, security, conformance to the design,
 test coverage) if the default scope is not obvious.
 
+Never pre-judge findings for the reviewer: do not instruct them to ignore or
+not flag a specific issue ("don't treat X as a defect", "at most minor"). If
+you believe a finding would be a false positive, let the reviewer raise it and
+resolve it with evidence in §Receiving — pre-judging is usually the requester
+sparing themselves a round.
+
 ## Receiving
 
 **MUST answer findings one by one — fix, or justify with evidence; why:
@@ -111,6 +117,22 @@ resolve a disagreement by rewording the finding until it goes away. When the
 project keeps a `REVIEW_LOG` (or equivalent), log the outcome of each
 finding there.
 
+### Review-driven corrections (scoped re-review)
+
+A fix made in response to a finding is new, unreviewed work — stopping after
+"I fixed it" ships the one version nobody reviewed. Every review-driven change
+therefore gets a **scoped re-review** before the review can PASS: hand the
+re-reviewer the original findings and ONLY the correction (the fix diff/range
+for code, the amended sections for a document), and require a per-finding
+verdict — `ADDRESSED`, `NOT ADDRESSED`, or `CONTESTED` with evidence. The
+re-review also checks the correction itself for new blocker-level
+breakage — and nothing else: out-of-scope observations become separately
+recorded findings, never an extension of the loop. Expect two rounds as the
+norm, not the exception — round 1 finds, round 2 verifies the fixes — inside
+the same cap of 3 (§When a review is due). One logical review stays ONE
+REVIEW_LOG row, its rounds narrated inside; a scoped re-review is a round,
+not a new review.
+
 ## Reviewing
 
 When you are the reviewer:
@@ -123,6 +145,12 @@ When you are the reviewer:
   (see `## Requesting`).
 - Cite evidence as `file:line` for every finding — a finding without a
   location is not actionable.
+- **Say what you could NOT verify.** When a claim in the artifact cannot be
+  verified from the inputs you were given (it lives in unchanged code, another
+  document, or an environment you cannot reach), report it as a
+  `CANNOT VERIFY` item instead of silently passing it — the requester holds
+  the context to resolve it, and must do so before closing. A PASS that
+  silently skipped unverifiable claims is review theater.
 - Keep severity honest: do not inflate a style preference to a blocker, and
   do not soften a real correctness or security issue to a nit.
 - No praise padding. A review reports problems and their fixes, not a
@@ -159,6 +187,21 @@ When you are the reviewer:
   review, never replacing it; coverage of each use-case by the Impact, and the
   Actor it serves, stay the conformance-statement clause above. A lens whose
   template defines no `## Use Cases` section never fires this clause.
+- **Functional Spec (same reviews; fires only in the lens whose template defines
+  the section — the code lens today).** When the change adds or alters observable
+  behavior (the trigger's owning definition is the code lens's `templates.md`
+  `## Functional Spec` section comment — cite it, never restate it), **an L3
+  artifact carrying NO `## Functional Spec` is itself a finding** — absence is
+  what a skipped spec looks like, not a reason to skip the check. When the spec
+  is there, these findings live here: **a component, file or mechanism named
+  inside it** — the spec is component-free by construction; that is
+  Solution-leakage (component names belong to the Interface Contract, mechanism
+  to the Impact); a behavior whose edge, error or state-dependent cases are
+  absent with no stated reason; an acceptance criterion no `## Test Strategy`
+  item covers; a behavior serving no use case, or a use case whose behavior the
+  spec leaves unstated; and an Interface Contract flow realizing a behavior the
+  spec does not state. A lens whose template defines no such section (knowledge,
+  marketing) never fires this clause.
 - **Capability Ledger (same reviews).** **An L3 impact/solution analysis or design
   that carries NO Capability Ledger is itself a finding** — the lens's capability
   pass (`architect.md` in the code lens, `taxonomy.md` in the knowledge lens) left