@elevasis/core 0.38.0 → 0.39.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@elevasis/core",
-  "version": "0.38.0",
+  "version": "0.39.0",
   "license": "MIT",
   "description": "Minimal shared constants across Elevasis monorepo",
   "sideEffects": false,

package/src/platform/registry/validation.ts

@@ -23,6 +23,7 @@ import {
   computeInterfaceReadiness,
   type SystemInterfaceReadinessIssueFamily
 } from '../../business/acquisition/ontology-validation'
+import { SYSTEM_INTERFACE_PROFILES } from '../../organization-model/domains/systems'
 import type { OmTopologyNodeRef } from '../../organization-model/domains/topology'
 import type {
   TriggerDefinition,
@@ -615,20 +616,28 @@ function addSystemInterfaceIssue(
 
 /**
  * Detects systems that are API-backed (have resources with non-empty ontology
- * bindings) but have not declared `apiInterface` in the Organization Model.
+ * bindings), CAN adopt a platform-cataloged `apiInterface` readinessProfile
+ * (system path appears in `SYSTEM_INTERFACE_PROFILES`), but have not declared
+ * `apiInterface` in the Organization Model.
  *
- * Broad-by-design — tighten via test-driven counterexample.
- * See _execution-plan.mdx Decision 1.
+ * Originally broad-by-design (flagged any system with ontology actions/writes
+ * lacking apiInterface). Tightened in @elevasis/sdk@1.30.1 after the template
+ * surfaced the unactionable-paradox case: custom systems (e.g. `sys.operations`,
+ * `sys.notifications`) have valid `ontology.actions` bindings but cannot adopt
+ * one of the closed-catalog readiness profiles, AND the documented guidance
+ * ("Custom Systems should not declare apiInterface") is incompatible with the
+ * broad heuristic. The gate now only flags systems where adoption is even
+ * possible — i.e. the system path matches a cataloged profile's `systemPath`.
  *
- * A system is flagged when:
+ * A system is flagged when ALL of:
  *   (a) `system.apiInterface === undefined`, AND
  *   (b) at least one resource in `organizationModel.resources` has
  *       `resource.systemPath` matching the system path AND
- *       `resource.ontology` non-empty (has `actions` and/or `writes` defined).
+ *       `resource.ontology` non-empty (has `actions` and/or `writes` defined), AND
+ *   (c) the system path appears as a cataloged `systemPath` in
+ *       `SYSTEM_INTERFACE_PROFILES` (so adopting a profile is actually possible).
  *
  * Returns `[]` when `organizationModel` is undefined or no gaps are found.
- * The structured return value drives both CLI warnings and scaffold fill-mode
- * input payloads without any transformation on the caller side.
  */
 export function detectMissingApiInterfaceDeclarations(
   orgName: string,
@@ -655,10 +664,15 @@ export function detectMissingApiInterfaceDeclarations(
 
   if (apiBoundResourcesBySystemPath.size === 0) return []
 
+  // Closed-catalog filter: a system is only a candidate for missing apiInterface
+  // if it could actually adopt one of the cataloged platform profiles.
+  const catalogedSystemPaths = new Set<string>(SYSTEM_INTERFACE_PROFILES.map((profile) => profile.systemPath))
+
   const gaps: ApiInterfaceConformanceGap[] = []
 
   for (const { path, system } of listAllSystems(organizationModel)) {
     if (system.apiInterface !== undefined) continue
+    if (!catalogedSystemPaths.has(path)) continue
     const resourceIds = apiBoundResourcesBySystemPath.get(path)
     if (!resourceIds || resourceIds.length === 0) continue
     gaps.push({