yarramate 1.14.1 → 1.15.0

package/dist/design-command.js

@@ -81,6 +81,43 @@ const localKind = (qualified) => {
     const hash = qualified.lastIndexOf('#');
     return hash === -1 ? qualified : qualified.slice(hash + 1);
 };
+/**
+ * The `missing-claim` predicates that name a CONCEPT FIELD, and the field
+ * each one is written through (#430).
+ *
+ * `missing-claim` matches a raw predicate, and a predicate is not an
+ * authoring gesture: `yarramate/attestation/adequacy` is written by adding an
+ * attestation, `yarramate/reference/refers-to` by adding a reference, and a
+ * profile may mint predicates this engine has never heard of. So the
+ * condition cannot map to one operation in general, which is why an adopter
+ * wiring it up got a card with no affordance and filed #430.
+ *
+ * It maps for these three, and only these three, because each is a named
+ * field on a concept that `update-concept` writes directly. They are Core's
+ * own, closed, and they are every `missing-claim` the shipped catalogue uses
+ * — `owner-missing`, `information-unowned`, `concept-undescribed` and
+ * `status-missing`. Anything else returns no skeleton, which is ADR 0110's
+ * rule holding: a wrong skeleton is never offered.
+ *
+ * This is the "one new mapping case" ADR 0110 anticipated, not a remedy DSL.
+ * The engine still takes no position on which predicates a HOST should render
+ * as editable; the trigger carries the predicate and the host decides. This
+ * is the CLI rendering its own affordance, the same as the other two cases.
+ */
+const CONCEPT_FIELD_PREDICATES = {
+    'yarramate/ownership/owner': {
+        name: 'owner',
+        placeholder: '<owning-subject-id>',
+    },
+    'yarramate/concept/description': {
+        name: 'description',
+        placeholder: '<one line>',
+    },
+    'yarramate/lifecycle/status': {
+        name: 'status',
+        placeholder: '<planned|current|retired>',
+    },
+};
 const skeletonHeader = (documentAddress, op) => [
     '',
     'Prefilled skeleton (edit the <placeholders>, save as operations.yaml):',
@@ -125,6 +162,17 @@ const renderSkeleton = (step, documentAddress) => {
             `        to: ${to}`,
         ];
     }
+    if (condition.condition === 'missing-claim' && step.subject !== undefined) {
+        const field = CONCEPT_FIELD_PREDICATES[condition.predicate];
+        if (field === undefined)
+            return [];
+        return [
+            ...skeletonHeader(documentAddress, 'update-concept'),
+            '      concept:',
+            `        id: ${step.subject.id.split('#').pop()}`,
+            `        ${field.name}: ${field.placeholder}`,
+        ];
+    }
     return [];
 };
 export function runDesignCommand(options, cwd) {

package/dist/interrogate-command.d.ts

@@ -110,6 +110,35 @@ export type CatalogueCondition = {
     readonly direction: 'incoming' | 'outgoing' | 'either';
     readonly counterpartKinds: readonly string[];
     readonly kindMatching?: 'exact' | 'descendants';
+} | {
+    /**
+     * The negative twin of `exists-linkage`, workspace-scope like it
+     * (#436, ADR 0138). Fires while NO concept in the workspace satisfies
+     * the linkage, so a question can ask "nothing anywhere links this way".
+     *
+     * It exists because a **vocabulary question** was asking the wrong
+     * thing. `below-subject-count` measures a population, and a vocabulary
+     * question means "did anyone survey this" — a proxy that fails in both
+     * directions, measured on a live engagement: two throwaway values close
+     * it dishonestly, while a truthful single-value estate can never close
+     * it at all.
+     *
+     * `MODEL-FLOOR.md` prescribes the answer's home: a classification axis
+     * is a `grouping` that aggregates its members, so a scheme aggregating
+     * its classes IS the statement that these are the classes. Asking "no
+     * scheme aggregates any class" needs this condition; asking how many
+     * classes exist does not reach it.
+     *
+     * Deliberately NOT `!exists-linkage` in the evaluator, for the reason
+     * `has-subject-of-kind` is not `!no-subject-of-kind`: written as its own
+     * check, an empty workspace falls out right rather than by double
+     * negative.
+     */
+    readonly condition: 'no-linkage-exists';
+    readonly kinds: readonly string[];
+    readonly direction: 'incoming' | 'outgoing' | 'either';
+    readonly counterpartKinds: readonly string[];
+    readonly kindMatching?: 'exact' | 'descendants';
 } | {
     readonly condition: 'missing-constraint';
     readonly kinds: readonly string[];

package/dist/interrogate-command.js

@@ -207,6 +207,7 @@ const namedKinds = (question) => {
             case 'missing-linkage':
             case 'has-linkage':
             case 'exists-linkage':
+            case 'no-linkage-exists':
                 kinds.push(...condition.kinds, ...condition.counterpartKinds);
                 break;
             default:
@@ -267,6 +268,7 @@ const CONDITION_SCOPE = {
     'below-subject-count': 'workspace',
     'no-state-defined': 'workspace',
     'exists-linkage': 'workspace',
+    'no-linkage-exists': 'workspace',
     'missing-claim': 'subject',
     'missing-relationship': 'subject',
     isolated: 'subject',
@@ -413,6 +415,11 @@ const conditionHolds = (index, condition, subjectId, profileContext, evidence, m
                 linkageHits(index, condition, subjectId, profileContext));
         case 'exists-linkage':
             return [...index.concepts].some((id) => linkageHits(index, condition, id, profileContext));
+        case 'no-linkage-exists':
+            // Its own check rather than `!exists-linkage`, so an empty workspace
+            // falls out right: no concepts means no linkage, which is exactly the
+            // model a vocabulary question is loudest about.
+            return ![...index.concepts].some((id) => linkageHits(index, condition, id, profileContext));
         case 'missing-constraint': {
             const matching = condition.kindMatching ?? 'descendants';
             return !(index.claimsBySubject.get(subjectId) ?? []).some((claim) => claim.predicate === 'yarramate/constraint/requires' &&