@ogygie/core 0.13.0 → 0.13.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ogygie/core",
-  "version": "0.13.0",
+  "version": "0.13.1",
   "description": "Ogygie framework core: manifest/spec/error schemas, generic tenancy and gate tooling. Ships TypeScript sources — Ogygie products run tsx/vitest by construction (D1).",
   "license": "MIT",
   "type": "module",

package/src/manifest-owners.test.ts

@@ -5,7 +5,8 @@
  * confirm, and that neither shadows the other.
  */
 import { describe, expect, it } from "vitest";
-import { declaredEntries, findSpecOwner } from "./manifest-owners.js";
+import { declaredEntries, findSpecOwner, hasImplementation } from "./manifest-owners.js";
+import type { SpecOwner, SpecOwnerKind } from "./manifest-owners.js";
 import { OgygieManifestSchema } from "./manifest.schema.js";
 
 function manifestWith(extra: Record<string, unknown>) {
@@ -250,3 +251,30 @@ describe("declaredEntries — tout ce que la carte déclare, à un seul endroit"
     expect(declaredEntries(withApps({}))).toEqual([]);
   });
 });
+
+describe("hasImplementation — ce qui prouve qu'une spec draft a déjà du code", () => {
+  const owner = (
+    kind: SpecOwnerKind,
+    status: "skeleton" | "in-progress" | "delivered",
+  ): SpecOwner => ({ kind, name: "peu-importe", status, folder: "un/chemin" });
+
+  it("ÉTANT DONNÉ un statut au-delà de skeleton ALORS l'implémentation existe, dossier ou pas", () => {
+    for (const kind of ["feature", "package", "framework-package"] as SpecOwnerKind[]) {
+      expect(hasImplementation(owner(kind, "in-progress"), false)).toBe(true);
+      expect(hasImplementation(owner(kind, "delivered"), false)).toBe(true);
+    }
+  });
+
+  it("une FEATURE skeleton dont le dossier existe a bien du code — c'est la preuve historique", () => {
+    expect(hasImplementation(owner("feature", "skeleton"), true)).toBe(true);
+    expect(hasImplementation(owner("feature", "skeleton"), false)).toBe(false);
+  });
+
+  it("MUTATION : un PACKAGE skeleton dont le dossier existe n'a PAS de code — le manifeste EXIGE ce dossier", () => {
+    // Sans cette règle, une spec draft et un package skeleton ne peuvent pas
+    // coexister : verify-manifest réclame le dossier, verify-specs y lit du
+    // code, et le projet est coincé entre deux fichiers gouvernés.
+    expect(hasImplementation(owner("package", "skeleton"), true)).toBe(false);
+    expect(hasImplementation(owner("framework-package", "skeleton"), true)).toBe(false);
+  });
+});

package/src/manifest-owners.ts

@@ -158,6 +158,28 @@ export function findSpecOwner(
   return { kind: owner.kind, name: owner.name, status: owner.status, folder: owner.folder };
 }
 
+/**
+ * Does an implementation of this spec exist? The question the `draft` rule of
+ * the spec lifecycle rests on ("draft = no code yet").
+ *
+ * A declared status above `skeleton` always answers yes. A FOLDER on disk only
+ * answers yes for a FEATURE, whose folder is born with its code and is
+ * therefore evidence of it. A package's folder is NOT evidence: the manifest
+ * gate REQUIRES it to exist (MANIFEST_PACKAGE_NOT_FOUND), so a package
+ * declared `skeleton` whose spec is still `draft` could satisfy neither gate —
+ * one demands the folder, the other reads it as code, and the project is stuck
+ * between two governed files it may not edit. Observed on a consumer project
+ * the day it declared its first package before writing it.
+ *
+ * Lives here rather than in the gate script for the reason the whole module
+ * exists: the rule travels with the versioned package, not with a copy each
+ * project keeps.
+ */
+export function hasImplementation(owner: SpecOwner, folderExists: boolean): boolean {
+  if (owner.status !== "skeleton") return true;
+  return owner.kind === "feature" && folderExists;
+}
+
 /** What a refusal should suggest — both natures, never one that cannot exist. */
 export const SPEC_OWNER_FIX =
   "Set the owning entry to delivered in the manifest — a feature under `features`, a library under `packages`, or a published package under `framework.packages` (which names its spec explicitly) — or keep the spec in validated.";