gennady 0.9.0-next.3 → 0.9.0-next.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -278,6 +278,7 @@
278
278
  Missing ticket → `TASK_ID_DRIFT` (`MAJOR`).
279
279
  - Two ticket files declaring same Task-ID → `TASK_ID_DRIFT` (`BLOCKER`).
280
280
  - Compare current `@tasks:` field values against pre-task git ref. Prior IDs removed → `TASK_ID_DRIFT` (`MAJOR`).
281
+ - **Spec-anchor references resolve (SSOT, advisory).** Per scaffold `AX_SSOT_TRACEABILITY` a ticket references spec facts by anchor rather than restating them. Each Markdown anchor link from the ticket into a spec must resolve to a real section/heading. A dangling reference (spec anchor renamed or removed) → `INFO` tagged `dangling-spec-ref`: the reader is sent to a fact that no longer exists. Structural check only — verify the anchor exists; never compare the referenced value against a restated copy (by design there is none).
281
282
  - **Ticket section-anchor coverage** (per scaffold `AX_TICKET_SECTION_NAMES_NORMATIVE`). For
282
283
  each anchor name templated in `TASK_TICKET_STRUCTURE` invoke
283
284
  `<sdd-path> extract <ticket> <NAME>`, using the exact absolute tool path supplied by the
@@ -142,6 +142,7 @@
142
142
  - At least one phase of kind `test` MUST exist whose Target Files contains the test file, unless every scenario has `Deferred Test Ownership`.
143
143
  - Canonical case names are normative: phase-subagent uses verbatim or updates the ticket before phase DONE.
144
144
  - BDD describes behavior, not language-specific syntax.
145
+ - A scenario's expected outcome REFERENCES the spec's canonical fact by anchor (e.g. "error per spec §Error Format"); it does not paste the literal message or value (per `AX_SSOT_TRACEABILITY`). The verifying test carries the literal; the BDD carries the intent and the reference. Concrete input instances in `Given` stay literal — they are the scenario's own data, not a restated spec fact.
145
146
  - For every DbC contract in Spec References (Port / Adapter / Value Object / branded type / discriminated union): one `contract`-level typing scenario MUST exist — covers input/output shape, branded-type rejection at boundary, union exhaustiveness. `Deferred Test Ownership` not allowed for typing scenarios — they ship with the types.
146
147
  </Axiom>
147
148
 
@@ -264,7 +265,20 @@
264
265
  </Axiom>
265
266
 
266
267
  <Axiom id="AX_SSOT_TRACEABILITY">
267
- **No contract duplication.** Tickets link to spec sections via Markdown anchors. Module spec for contracts/consumers/invariants; scope spec 4 only for cross-cutting constraints.
268
+ **No duplication of a canonical fact — reference it, do not restate it.** A fact fixed in the
269
+ spec (error-message format, behavior rule, requirement text, signature, contract) has ONE home:
270
+ the spec. Tickets link to it by Markdown anchor; they never paste the literal. A BDD `Then` names
271
+ the spec fact ("error matches spec §Error Format"), it does not re-type the message string.
272
+ Module spec for contracts/consumers/invariants; scope spec 4 only for cross-cutting constraints.
273
+
274
+ The executable literal (the actual error string, the real signature) lives ONLY in the code and
275
+ its test — that pair is the executable projection, kept honest by the test run, not by hand. A
276
+ doc that restates such a literal is drift waiting to happen: an ordinary narrow edit updates the
277
+ spec and code but leaves the doc copy stale, silently contradicting both. Distinct projections
278
+ are NOT duplication and stay: a scenario's concrete input instance (`MISSING_VAR`), the BDD shape
279
+ itself, the diagram, each type's own test. Referencing carries one risk — a dangling anchor — so
280
+ a reference must resolve to a real spec section; that is checkable structurally (does the anchor
281
+ exist), never by matching the value string (matching templates against instances cries wolf).
268
282
  </Axiom>
269
283
 
270
284
  <Axiom id="AX_DIALOGUE_DISCIPLINE">
@@ -278,6 +278,7 @@
278
278
  Missing ticket → `TASK_ID_DRIFT` (`MAJOR`).
279
279
  - Two ticket files declaring same Task-ID → `TASK_ID_DRIFT` (`BLOCKER`).
280
280
  - Compare current `@tasks:` field values against pre-task git ref. Prior IDs removed → `TASK_ID_DRIFT` (`MAJOR`).
281
+ - **Spec-anchor references resolve (SSOT, advisory).** Per scaffold `AX_SSOT_TRACEABILITY` a ticket references spec facts by anchor rather than restating them. Each Markdown anchor link from the ticket into a spec must resolve to a real section/heading. A dangling reference (spec anchor renamed or removed) → `INFO` tagged `dangling-spec-ref`: the reader is sent to a fact that no longer exists. Structural check only — verify the anchor exists; never compare the referenced value against a restated copy (by design there is none).
281
282
  - **Ticket section-anchor coverage** (per scaffold `AX_TICKET_SECTION_NAMES_NORMATIVE`). For
282
283
  each anchor name templated in `TASK_TICKET_STRUCTURE` invoke
283
284
  `<sdd-path> extract <ticket> <NAME>`, using the exact absolute tool path supplied by the
@@ -142,6 +142,7 @@
142
142
  - At least one phase of kind `test` MUST exist whose Target Files contains the test file, unless every scenario has `Deferred Test Ownership`.
143
143
  - Canonical case names are normative: phase-subagent uses verbatim or updates the ticket before phase DONE.
144
144
  - BDD describes behavior, not language-specific syntax.
145
+ - A scenario's expected outcome REFERENCES the spec's canonical fact by anchor (e.g. "error per spec §Error Format"); it does not paste the literal message or value (per `AX_SSOT_TRACEABILITY`). The verifying test carries the literal; the BDD carries the intent and the reference. Concrete input instances in `Given` stay literal — they are the scenario's own data, not a restated spec fact.
145
146
  - For every DbC contract in Spec References (Port / Adapter / Value Object / branded type / discriminated union): one `contract`-level typing scenario MUST exist — covers input/output shape, branded-type rejection at boundary, union exhaustiveness. `Deferred Test Ownership` not allowed for typing scenarios — they ship with the types.
146
147
  </Axiom>
147
148
 
@@ -264,7 +265,20 @@
264
265
  </Axiom>
265
266
 
266
267
  <Axiom id="AX_SSOT_TRACEABILITY">
267
- **No contract duplication.** Tickets link to spec sections via Markdown anchors. Module spec for contracts/consumers/invariants; scope spec 4 only for cross-cutting constraints.
268
+ **No duplication of a canonical fact — reference it, do not restate it.** A fact fixed in the
269
+ spec (error-message format, behavior rule, requirement text, signature, contract) has ONE home:
270
+ the spec. Tickets link to it by Markdown anchor; they never paste the literal. A BDD `Then` names
271
+ the spec fact ("error matches spec §Error Format"), it does not re-type the message string.
272
+ Module spec for contracts/consumers/invariants; scope spec 4 only for cross-cutting constraints.
273
+
274
+ The executable literal (the actual error string, the real signature) lives ONLY in the code and
275
+ its test — that pair is the executable projection, kept honest by the test run, not by hand. A
276
+ doc that restates such a literal is drift waiting to happen: an ordinary narrow edit updates the
277
+ spec and code but leaves the doc copy stale, silently contradicting both. Distinct projections
278
+ are NOT duplication and stay: a scenario's concrete input instance (`MISSING_VAR`), the BDD shape
279
+ itself, the diagram, each type's own test. Referencing carries one risk — a dangling anchor — so
280
+ a reference must resolve to a real spec section; that is checkable structurally (does the anchor
281
+ exist), never by matching the value string (matching templates against instances cries wolf).
268
282
  </Axiom>
269
283
 
270
284
  <Axiom id="AX_DIALOGUE_DISCIPLINE">
package/dist/gennady.js CHANGED
@@ -3,7 +3,7 @@ import { c as s } from "./chunks/shared-CCgxBhk_.js";
3
3
  import "node:fs";
4
4
  import "node:path";
5
5
  import "node:url";
6
- const r = "0.9.0-next.3", i = /* @__PURE__ */ new Set(["help", "--help", "-h"]), p = /* @__PURE__ */ new Set(["--version", "-v"]), t = process.argv[2];
6
+ const r = "0.9.0-next.4", i = /* @__PURE__ */ new Set(["help", "--help", "-h"]), p = /* @__PURE__ */ new Set(["--version", "-v"]), t = process.argv[2];
7
7
  p.has(t) && (console.log(r), process.exit(0));
8
8
  (!t || i.has(t)) && (await import("./chunks/help.cmd-Bz1YqU2V.js"), process.exit(0));
9
9
  s({ name: "gennady", version: r });
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "gennady",
3
- "version": "0.9.0-next.3",
3
+ "version": "0.9.0-next.4",
4
4
  "author": "Konstantin Lebedev <ibnrubaxa@gmail.com>",
5
5
  "description": "Gennady — General Extensible Neural Network Adaptive Data Yntelligence",
6
6
  "keywords": [