@antoneeo/agentic-sdlc-skill 1.30.0 → 1.31.0

package/CHANGELOG.md

@@ -2,6 +2,30 @@
 
 Tutte le modifiche significative a questa skill saranno documentate in questo file.
 
+## [1.31.0] - 2026-09-05
+
+### Changed
+- **Execute-Before-Specify now covers text-about-text (SKILL.md, Phase 3).** A
+  deliverable that is itself text -- doctrine, a schema, a prompt, a reviewer
+  definition -- is probed the same way as code: replay it against the recorded
+  case that motivated it (the incident artifact, the tool-usage transcript, the
+  review that missed the defect), red under the old text, green under the new.
+  "No probe is possible" is shown, never declared. The exemption an earlier
+  proposal would have granted was rejected on evidence: the unit cited as
+  unprobeable text was a code unit that modified six production modules and
+  shipped four assertion harnesses, while doctrine and prompt changes have been
+  measured here by replay (three headless probes of a prompt change; an ad-hoc
+  checklist that caught in one round what ten rounds missed). Paid for per this
+  skill's own `vision.md` cumulative-ratchet rule: 67 words of illustration and
+  rationale deleted from the same paragraph, net -2 words.
+- **Form budget belongs to the first draft (shared spine `review.md`,
+  byte-identical x3).** The lean operative form is the FIRST draft's form, not
+  the round-3 rescue: the review request states the artifact's line count
+  against a budget the author fixed before drafting, and an artifact over budget
+  is the reviewer's first finding, before content. The ~1,250 -> ~500 line
+  measurement already in the file is its anchor. Spine delta is synced in the
+  repo; kb and mkt ship it at their next release.
+
 ## [1.30.0] - 2026-09-01
 
 ### Added

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "agentic-sdlc-skill",
-  "version": "1.30.0",
+  "version": "1.31.0",
   "description": "Documentation-First SDLC protocol with triage, Vision governance and optional devPNT integration.",
   "author": "Antonio Pinto (https://github.com/Antoneeo)"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@antoneeo/agentic-sdlc-skill",
-  "version": "1.30.0",
+  "version": "1.31.0",
   "description": "Documentation-First SDLC protocol for Claude Code, Gemini CLI, Google Antigravity and Codex with risk triage, Vision governance, installed support files and optional devPNT integration.",
   "keywords": [
     "claude-code",

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

@@ -1,6 +1,6 @@
 ---
 name: agentic-sdlc
-version: 1.30.0
+version: 1.31.0
 description: Documentation-First SDLC protocol with risk-proportional triage, Vision as a guide, a complete Standalone mode and optional symbiosis with devPNT. Use for features, significant bugs, refactors, audits and documented maintenance.
 author: Antonio Pinto (https://github.com/Antoneeo)
 copyright: (c) 2026 Antonio Pinto
@@ -240,7 +240,7 @@ For any L3, run the spec elicitation round in `elicitation.md` BEFORE drafting t
 
 **Blast-radius enumeration is an authoring duty, not a review finding.** Before writing the Impact (the list of what changes), for every symbol whose signature you change, thread a new field through, or that has more than one caller: mechanically enumerate EVERY consumer with the best symbol-graph tool your toolchain offers — an LSP/IDE call hierarchy or a find-usages / call-graph capability — with `grep` only as a last-resort fallback, and list the full set in the Impact. Anchor to symbol identity, not line numbers (they rot). This is deterministic and cheap: doing it up-front collapses the review into one pass, instead of the reviewer returning "you missed a consumer" one round at a time. Leaving completeness to the closure review is the myopia failure this whole workflow exists to prevent.
 
-**Execute-Before-Specify — behavioural claims about existing code are probed, not read.** Every claim in an L3 design artifact of the form "the code today does X" — what a loader leaves behind on failure, which exception escapes a `try`, what a store publishes when its file is corrupt — MUST derive from an executed probe (a small script or assertion harness run against the real system in its real states) before the prose is written, never from reading the source alone. Reading is structurally insufficient for behaviour: an author who only reads cannot see that a called function does not exist, or that the exception they reasoned about is caught two frames down. The duty is proportional: it covers the claims the design RESTS on — where a wrong answer changes the design — never every mention of existing code; structural facts (a file exists, a symbol's signature, who calls it) belong to the blast-radius enumeration above, not to a probe. And a probe must be able to FAIL: show it red first — negate the condition or the state it asserts — then green against the real system (the RED gesture of `tdd.md`, applied to the experiment); a probe you cannot make fail establishes nothing, and a vacuous assertion is a read claim wearing a probe's clothes. Keep the probes as an assertion harness that ships WITH the artifact, in the repo (e.g. `ai_docs/solutions/harness_[feature]/` — a scratchpad dies with the session): the reviewer re-runs assertions instead of re-deriving claims, and every later revision re-verifies them for free. Field measurement (2026-08): eight consecutive design-review FAILs, every finding the class "the design describes intent, not behaviour", converged to a PASS in one round once each behavioural claim was executed first — probed claims held in every subsequent round; read claims failed in every one.
+**Execute-Before-Specify — behavioural claims about existing code are probed, not read.** Every claim in an L3 design artifact of the form "the code today does X" MUST derive from an executed probe (a small script or assertion harness run against the real system in its real states) before the prose is written, never from reading the source alone. The duty is proportional: it covers the claims the design RESTS on — where a wrong answer changes the design — never every mention of existing code; structural facts (a file exists, a symbol's signature, who calls it) belong to the blast-radius enumeration above, not to a probe. A deliverable that is itself text — doctrine, a schema, a prompt, a reviewer definition — is probed the same way: replay it against the recorded case that motivated it (the incident artifact, the tool-usage transcript, the review that missed the defect), red under the old text, green under the new. "No probe is possible" is shown, never declared. And a probe must be able to FAIL: show it red first — negate the condition or the state it asserts — then green against the real system (the RED gesture of `tdd.md`, applied to the experiment); a probe you cannot make fail establishes nothing. Keep the probes as an assertion harness that ships WITH the artifact, in the repo (e.g. `ai_docs/solutions/harness_[feature]/` — a scratchpad dies with the session): the reviewer re-runs assertions instead of re-deriving claims, and every later revision re-verifies them for free. Field measurement (2026-08): eight consecutive design-review FAILs, every finding the class "the design describes intent, not behaviour", converged to a PASS in one round once each behavioural claim was executed first — probed claims held in every subsequent round; read claims failed in every one.
 
 Standalone L3:
 - Before creating a new `ANALYSIS_[feature].md`, search `ai_docs/solutions/` with glob/grep for an existing analysis on the same topic: if there is one, update it instead of duplicating it.

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

@@ -98,10 +98,12 @@ unfalsifiable, the same defect as an unnamed EXISTS or a faked router verdict.
 own findings and can make the cap unreachable honestly. (1) *Patch-on-patch*:
 each round's fixes are grafted onto the previous text until stale counts,
 duplicated sections and internal contradictions are findings the revisions
-themselves created. When a round's findings are of that artifact-consistency
-class — and at the latest before a round-3 attempt — rewrite the artifact lean
-and operative against the checklist instead of patching again; a from-scratch
-rewrite is cheaper than a burned round. (2) *Revision narrative in the
+themselves created. The lean operative form is the FIRST draft's form, not the
+round-3 rescue: the review request states the artifact's line count against a
+budget the author fixed before drafting (default: the measured figure below), and
+an artifact over budget is the reviewer's first finding, before content. When a
+round's findings are of that artifact-consistency class, rewrite lean instead of
+patching again. (2) *Revision narrative in the
 artifact*: the artifact under review carries its own review archaeology
 ("v1.2 fixed…", "as the round-2 review noted…"). An artifact states what IS,
 once; how it got there lives in the REVIEW_LOG row's notes, never in the