yarramate 1.2.0 → 1.4.0

package/catalogues/core-enrichment.yaml

@@ -1,6 +1,6 @@
 format: yarramate/question-catalogue/v1
 id: core-enrichment
-version: "1.1"
+version: "1.3"
 profile: yarramate/core@0.1
 presentation:
   title: Core enrichment interview
@@ -25,27 +25,39 @@ waves:
       Load-bearing hops: the behavior a component is assigned to or the
       interface it composes, the serving/triggering/flow mechanism,
       payload, trust, reliability, and capacity. Hygiene waits.
+    opensWhen:
+      - condition: has-any-subject
   - id: business
     name: Business
     description: Who acts, what is served, and what information matters.
+    opensWhen:
+      - condition: has-any-subject
   - id: application
     name: Application
     description: >-
       How declared services are realized, performed, and fed with
       information.
+    opensWhen:
+      - condition: has-any-subject
   - id: technology
     name: Technology
     description: >-
       Where the declared applications actually run and what materializes
       them.
+    opensWhen:
+      - condition: has-any-subject
   - id: implementation
     name: Implementation
     description: >-
       How the planned architecture becomes real: work, deliverables, and
       the plateaus between here and there.
+    opensWhen:
+      - condition: has-any-subject
   - id: hygiene
     name: Model hygiene
     description: Cross-cutting completeness that keeps every wave honest.
+    opensWhen:
+      - condition: has-any-subject
 
 questions:
   # ---- motivation ----------------------------------------------------------
@@ -880,6 +892,67 @@ questions:
       Add the externally meaningful services and serve them to their
       consumers.
 
+  - id: no-capability-declared
+    wave: business
+    since: "1.2"
+    scope: workspace
+    trigger:
+      - condition: no-subject-of-kind
+        kinds:
+          - yarramate/core@0.1#capability
+    question: >-
+      No capability is declared. What can this system do, in its own terms?
+    askPlain: >-
+      Forget the parts list for a moment: what are the handful of things
+      this system is actually able to do for the people it serves?
+    materiality: >-
+      Capabilities name what the system can do apart from how it currently
+      does it; without them, investment and sourcing trade-offs can only be
+      argued in component names, and nothing in the model can say which
+      parts serve the same ability. A subject-driven interview never asks
+      about a layer with zero subjects, so an absent capability map reads
+      as a covered one until this question opens it.
+    authority: human
+    resolution: >-
+      Add the small set of capabilities this system provides — four to
+      seven usually carries the whole conversation — and relate each to
+      the services or components that realize it with realization.
+
+  - id: no-contract-declared
+    wave: business
+    since: "1.2"
+    scope: workspace
+    trigger:
+      - condition: exists-linkage
+        kinds:
+          - yarramate/core@0.1#serving
+          - yarramate/core@0.1#flow
+          - yarramate/core@0.1#triggering
+        direction: either
+        counterpartKinds:
+          - yarramate/core@0.1#applicationComponent
+          - yarramate/core@0.1#applicationInterface
+          - yarramate/core@0.1#applicationService
+          - yarramate/core@0.1#businessActor
+      - condition: no-subject-of-kind
+        kinds:
+          - yarramate/core@0.1#contract
+    question: >-
+      Interactions exist and no contract governs any of them. Which
+      agreements bind what this architecture exchanges?
+    askPlain: >-
+      Things here talk to each other and to the outside. Where is it
+      written down what each side may expect — the API description, the
+      published schema, the service agreement?
+    materiality: >-
+      A hop with no contract is renegotiated by every implementer who
+      touches it; compatibility and versioning obligations exist only
+      where the agreement is a subject someone can change deliberately.
+    authority: human
+    resolution: >-
+      Add a contract for each formal agreement and access it from the
+      behavior bound by it; realization from the data object or artifact
+      that embodies the agreement says where it lives.
 
   - id: service-realizes-no-motivation
     wave: business
@@ -1063,6 +1136,38 @@ questions:
       not perform application behavior: assign the actor to the business
       process that uses it and let the application service serve that
       process.
+  - id: no-event-declared
+    wave: application
+    since: "1.2"
+    scope: workspace
+    trigger:
+      - condition: no-subject-of-kind
+        kinds:
+          - yarramate/core@0.1#applicationEvent
+          - yarramate/core@0.1#businessEvent
+    question: >-
+      Nothing in this model reacts to an event. Does state change only
+      when something is called, or are there happenings the architecture
+      responds to?
+    askPlain: >-
+      Is everything here a direct request, or do things also happen on
+      their own — a message arrives, a job finishes, a threshold is
+      crossed — that the system has to react to?
+    materiality: >-
+      Whether change propagates by call or by event decides coupling,
+      ordering, and failure isolation. An event-driven seam modelled as
+      silence leaves every consumer to discover the event stream on its
+      own, and a repository full of event definitions the interview never
+      asked about reads as covered when it is absent.
+    authority: human
+    resolution: >-
+      Add the application or business events the system emits or responds
+      to and wire each with triggering from what raises it to what
+      responds. If there are genuinely none, that is a coupling decision
+      worth stating in a principle or a service description; this question
+      then stays on the agenda as the standing record that nobody has
+      declared one.
+
   - id: event-triggers-nothing
     wave: application
     since: "0.3"
@@ -1232,6 +1337,31 @@ questions:
       Add realization from the node, system software, or technology
       behavior that provides the service.
 
+  - id: no-artifact-declared
+    wave: technology
+    since: "1.2"
+    scope: workspace
+    trigger:
+      - condition: no-subject-of-kind
+        kinds:
+          - yarramate/core@0.1#artifact
+    question: >-
+      No artifact is declared. What do the declared components actually
+      ship as?
+    askPlain: >-
+      When this system is deployed, what is the thing that moves — an
+      image, a package, a bundle? What are those called?
+    materiality: >-
+      Release engineering starts where a build output becomes a subject.
+      An architecture with components but no artifacts can say what should
+      exist and nothing about what is deployed, so drift between built and
+      declared has nowhere to register.
+    authority: human
+    resolution: >-
+      Add the artifacts the build produces, assignment from the node that
+      deploys each one, and realization from the artifact to the component
+      or data object it materializes.
+
   - id: artifact-unassigned
     wave: technology
     since: "0.4"
@@ -1258,6 +1388,37 @@ questions:
       realization from the artifact to the component or data object it
       materializes.
   # ---- implementation ------------------------------------------------------
+  - id: implementation-path-missing
+    wave: implementation
+    since: "1.2"
+    scope: workspace
+    trigger:
+      - condition: no-subject-of-kind
+        kinds:
+          - yarramate/core@0.1#workPackage
+          - yarramate/core@0.1#deliverable
+          - yarramate/core@0.1#plateau
+    question: >-
+      No work package, deliverable, or plateau is declared. How does the
+      planned architecture become real?
+    askPlain: >-
+      Who is doing what to get from here to there? What are the packages
+      of work, and what does each one hand over?
+    materiality: >-
+      A model that names a target but no work reaching it is a wish with
+      an architecture diagram; committed work packages and their
+      deliverables are what make progress reviewable rather than
+      reported. A repository mid-migration that models none of the
+      migration is the sharpest form of the gap: the change is in the
+      tree and invisible in the model.
+    authority: human
+    resolution: >-
+      Add the work packages in flight, realization to the deliverables
+      each produces, and plateaus where an intermediate state needs a
+      name. An architecture genuinely at rest keeps this question open,
+      which is itself information: the model is saying nothing is
+      changing.
+
   - id: workpackage-delivers-nothing
     wave: implementation
     since: "0.4"
@@ -1426,6 +1587,36 @@ questions:
     resolution: >-
       Add a description claim stating meaning and explicit exclusions.
 
+  - id: capability-uncited
+    wave: hygiene
+    since: "1.2"
+    scope: subject
+    subjects:
+      kinds:
+        - yarramate/core@0.1#capability
+    trigger:
+      - condition: missing-reference
+        predicate: yarramate/reference/refers-to
+        direction: outgoing
+    question: >-
+      {subject.name} cites nothing. Where is this ability specified,
+      decided, or documented?
+    askPlain: >-
+      If someone asked where it says the system can do
+      "{subject.name}", what would you point at?
+    materiality: >-
+      A capability with no citation floats free of every record that
+      could confirm or correct it: an audit has nothing to grade the
+      claim against, and when its scope is disputed the dispute starts
+      from memory. The reference is where the model meets the
+      repository's own account of itself.
+    authority: either
+    resolution: >-
+      Add a references entry from the capability to the subject that
+      specifies it — the decision record, the published schema, the
+      guide that documents the journey. Model that record as a subject
+      first where it is not one yet.
+
   - id: status-missing
     wave: hygiene
     since: "0.1"
@@ -1479,6 +1670,12 @@ questions:
       genuinely different, say so in the model: add the counterpart's id to
       this subject's distinctFrom list. That answer is itself a claim, so it
       closes the question permanently and survives re-running the interview.
+      A third answer is ordinary in a repository mid-migration: they are
+      different subjects and one is taking over from the other. Record the
+      succession with supersedes, scoped where the takeover is partial
+      (ADR 0109), and record distinctFrom alongside it. Succession says what
+      the pair is to each other and distinctness is what this question asks,
+      so only the second closes it.
 
   - id: states-undefined
     wave: hygiene
@@ -1489,13 +1686,24 @@ questions:
     question: >-
       Does change shape matter here — should baseline, transition, or target
       states be declared?
+    askPlain: >-
+      Are we describing how things are, how they should become, or both?
+      If the repository already carries a migration plan or a target
+      design, that document is the answer.
     materiality: >-
       Without architecture states, current and target intent share one
-      undifferentiated model and comparisons are impossible.
+      undifferentiated model and comparisons are impossible. The answer is
+      often already on the record: a repository that carries its own
+      migration plan or target design in-tree has declared that change
+      shape matters, so evidence can bring this question its answer rather
+      than waiting for someone to remember it.
     authority: human
     resolution: >-
       Declare architecture states and mark presence with present-in where the
       distinction carries decisions; explicitly decline states otherwise.
+      Where in-tree documents already describe the target, model that
+      record and cite it with references from the subjects it changes, so
+      the declared states stand on evidence a reviewer can open.
 
   - id: kind-untested
     wave: hygiene
@@ -1580,3 +1788,30 @@ questions:
       which says the same thing without a qualifier. If the two subjects
       simply coexist and neither takes over from the other, the succession
       is the wrong claim; remove it.
+
+  - id: evidence-unchallenged
+    wave: hygiene
+    since: "1.2"
+    scope: workspace
+    trigger:
+      - condition: unchallenged-evidence
+    question: >-
+      Every observation this workspace records is a frictionless
+      confirmation. Did the inspection ever test a claim it might fail?
+    askPlain: >-
+      The evidence agrees with the model everywhere. Did we ever look
+      for something that might not be there — a documented piece missing
+      from the tree, a declared dependency nothing carries?
+    materiality: >-
+      An overlay that only ever says confirmed is indistinguishable from
+      one that only looked where success was guaranteed. One recorded
+      search or one honest non-confirmation is what makes the agreement
+      between model and reality worth believing; a reconcile summary of
+      pure confirmations has never put a claim at risk.
+    authority: either
+    resolution: >-
+      Probe at least one claim the sources assert that the tree might not
+      honour, and record the observation with its honest result. A
+      not-observed carries the searches that came back empty (ADR 0107);
+      a confirmed negative claim carries them too, because the empty
+      search is the confirmation. Either closes this.

package/dist/adapters/visual/session-server.js

@@ -109,6 +109,21 @@ const LIMIT_FREEZE = {
 };
 /** Built browser application, beside the compiled adapter in `dist`. */
 const DEFAULT_ASSET_ROOT = fileURLToPath(new URL("../../visual-app/", import.meta.url));
+/**
+ * The shipped question catalogue, read once per process for the model's
+ * interrogation overlay (#292). The same package-relative hop `design`
+ * makes; `undefined` when unreadable, which ships models with no overlay
+ * rather than failing the session over a garnish.
+ */
+const shippedCatalogue = (() => {
+    const path = fileURLToPath(new URL("../../../catalogues/core-enrichment.yaml", import.meta.url));
+    try {
+        return { path, source: readFileSync(path, "utf8") };
+    }
+    catch {
+        return undefined;
+    }
+})();
 /**
  * Takes one session terminal, whatever caused it: a reviewer's End, a child
  * that failed, a browser that never came back, a cancelling main agent, or a
@@ -550,7 +565,7 @@ export const startVisualServer = async (options) => {
                 // that. A staged view operation pins against these (ADR 0103), and a
                 // projection missing from the map is one the commit will create.
                 projectionDigests: projectionDigestsNow(),
-            });
+            }, shippedCatalogue);
             // Closures below retain this array, so refresh its contents without
             // replacing the identity the session started with.
             views.splice(0, views.length, ...workspaceModel.views);

package/dist/adapters/visual/view-identity.d.ts

@@ -59,7 +59,7 @@ export declare const declaredFolder: (view: {
  *
  * Every other presentation field the view declared is carried through by
  * `composeProjection`, so a rename cannot quietly drop a nesting vocabulary or
- * a direction the canvas never showed.
+ * the direction the view runs.
  */
 export declare const renameView: (view: SavedView, title: string) => {
     readonly path: string;

package/dist/adapters/visual/view-identity.js

@@ -71,7 +71,7 @@ export const declaredFolder = (view) => view.presentation?.folder ?? "";
  *
  * Every other presentation field the view declared is carried through by
  * `composeProjection`, so a rename cannot quietly drop a nesting vocabulary or
- * a direction the canvas never showed.
+ * the direction the view runs.
  */
 export const renameView = (view, title) => ({
     path: view.path,
@@ -137,8 +137,9 @@ export const enumeratesSubjects = (query) => query.subjects !== undefined;
  * it was is a row the reviewer has to read and discard for nothing.
  */
 export const withMembership = (projection, subjectId, membership) => {
-    if (!enumeratesSubjects(projection.query))
-        return null;
+    if (!enumeratesSubjects(projection.query)) {
+        return withExclusion(projection, subjectId, membership);
+    }
     const subjects = projection.query.subjects;
     const holds = subjects.includes(subjectId);
     if (membership === "add" ? holds : !holds)
@@ -155,6 +156,45 @@ export const withMembership = (projection, subjectId, membership) => {
         },
     };
 };
+/**
+ * The same faceted view, holding one more exception or one fewer (#267,
+ * ADR 0122).
+ *
+ * A view that describes its subjects with facets states a RULE, and there is
+ * no list to edit — which is why membership used to stop here. But every
+ * interesting rule has an exception, and `exclude` is where the author writes
+ * one down instead of abandoning the facet for a hand-enumerated list. So
+ * "remove from view" names the subject in `exclude`, and "add to this view"
+ * takes the name back out.
+ *
+ * The asymmetry is deliberate and is the whole reason there is no `include`
+ * tier here: taking an exception BACK is expressible, while adding a subject
+ * the facets do not select is not — that would silently convert the rule into
+ * a list. A subject that is neither excluded nor selected therefore gets
+ * `null`, the same answer this returns for every other no-op.
+ *
+ * `exclude` is a statement about the rule rather than about today's match set,
+ * so it is written whether or not the subject happens to be drawn: a model
+ * that later grows into the facet still honours the decision someone made.
+ */
+const withExclusion = (projection, subjectId, membership) => {
+    const excluded = projection.query.exclude ?? [];
+    const isExcluded = excluded.includes(subjectId);
+    if (membership === "add" ? !isExcluded : isExcluded)
+        return null;
+    const next = membership === "add"
+        ? excluded.filter((id) => id !== subjectId)
+        : // Appended rather than sorted in, the rule the subjects list follows.
+            [...excluded, subjectId];
+    // The last exception leaving takes the key with it: `exclude: []` says the
+    // same thing as no key at all, and the schema's `minItems` refuses it
+    // anyway. Rebuilt rather than spread-over so the key is genuinely absent.
+    const { exclude: _dropped, ...rest } = projection.query;
+    return {
+        ...projection,
+        query: next.length === 0 ? rest : { ...rest, exclude: next },
+    };
+};
 /**
  * What a membership edit did to a view, as the tray reads it: `+id` for a
  * subject this row adds, `-id` for one it drops, against the document the
@@ -162,6 +202,24 @@ export const withMembership = (projection, subjectId, membership) => {
  * query, a presentation flag — which the row says by other means.
  */
 export const membershipDelta = (saved, staged) => {
+    if (!enumeratesSubjects(saved) && !enumeratesSubjects(staged)) {
+        // A faceted view's membership moves through `exclude`, and reads inverted
+        // there: a name ARRIVING in the exclusion list is a subject leaving the
+        // view (#267). The tray says what happened to the view, not what happened
+        // to the list.
+        const savedExclusions = saved.exclude ?? [];
+        const stagedExclusions = staged.exclude ?? [];
+        return [
+            ...savedExclusions
+                .filter((id) => !stagedExclusions.includes(id))
+                .map((id) => `+${id}`),
+            ...stagedExclusions
+                .filter((id) => !savedExclusions.includes(id))
+                .map((id) => `-${id}`),
+        ];
+    }
+    // One side enumerates and the other does not: the query changed shape rather
+    // than its membership, which the row says by other means.
     if (!enumeratesSubjects(saved) || !enumeratesSubjects(staged))
         return [];
     return [

package/dist/adapters/visual/wire.d.ts

@@ -10,11 +10,41 @@ import type { VISUAL_PROTOCOL_VERSION, VisualApplyResultPayload, VisualAuthority
  * that serves it — this module holds types only, and every dependency it has on
  * the protocol is type-only too.
  */
+/** One open question, as the question panel and a node's chip read it. */
+export interface VisualQuestionEntry {
+    readonly questionId: string;
+    /** Rendered phrasing — per-subject questions arrive already interpolated. */
+    readonly question: string;
+    readonly authority: 'human' | 'agent' | 'either';
+    readonly since?: string;
+}
+/**
+ * The interrogation report, folded for drawing (#292).
+ *
+ * Derived per successful recompile from the same compile the graph came
+ * from, and never stored — the stateless-interview rule as the canvas sees
+ * it. Optional on the model: a host that computes no overlay ships none,
+ * and the app draws no chips rather than zeros.
+ */
+export interface VisualInterrogationOverlay {
+    /** `id@version` of the catalogue that asked. */
+    readonly catalogue: string;
+    /** Engine condition-semantics version (ADR 0106), carried so a consumer
+     * can tell "the model moved" from "the engine moved". */
+    readonly semantics: string;
+    /** Workspace-scoped open questions — they name no subject, so they are
+     * shown when nothing is selected rather than pinned to a node. */
+    readonly workspace: readonly VisualQuestionEntry[];
+    /** Open questions per qualified subject id — `CanvasNode.id`'s space. */
+    readonly subjects: Readonly<Record<string, readonly VisualQuestionEntry[]>>;
+}
 /** The resolved graph a session renders, as the browser receives it. */
 export interface VisualRenderedModel {
     readonly authority: VisualAuthority;
     readonly initialView: string;
     readonly graph: CanvasGraph;
+    /** Present only when the host evaluated the catalogue for this compile. */
+    readonly interrogation?: VisualInterrogationOverlay;
     /** Manifest-relative document paths — the add-concept target dropdown. */
     readonly documents: readonly string[];
     readonly vocabulary: {

package/dist/adapters/visual/workspace-model.d.ts

@@ -5,7 +5,7 @@ import type { VisualDiagnostic, VisualViewOperation } from "./protocol-contract.
 import type { ProjectionDefinition, ProjectionExclusion, ProjectionQuery } from "../../projection.js";
 import type { ResolvedProfileContext, SemanticGraph } from "../../compiler.js";
 import type { VisualKindOption, VisualViewSummary } from "./protocol-contract.js";
-import type { VisualRenderedModel } from "./wire.js";
+import type { VisualInterrogationOverlay, VisualRenderedModel } from "./wire.js";
 /**
  * What a workspace looks like to the editor, however the editor is being run
  * (#252).
@@ -41,17 +41,49 @@ export declare const kindOptionsOf: (lineages: ReadonlyMap<string, readonly stri
  * them would read as five, and the reviewer counting boxes would find three.
  */
 export declare const conceptCountOf: (graph: SemanticGraph, query: ProjectionQuery, profileContext: ResolvedProfileContext) => number;
+/**
+ * Folds one interrogation report into what the canvas draws (#292).
+ *
+ * Undefined — never a throw — when the catalogue does not load: the overlay
+ * is a garnish on the model, and a model frame must not be blocked by it.
+ * Subject ids come from the same compiled graph as `CanvasNode.id`, so the
+ * join in the browser is a plain lookup.
+ */
+export interface DismissedQuestion {
+    readonly questionId: string;
+    /** Absent dismisses the question wherever it appears. */
+    readonly subject?: string;
+}
+export declare const interrogationOverlayOf: (compiled: {
+    readonly graph: SemanticGraph;
+    readonly profileContext: ResolvedProfileContext;
+}, catalogue: {
+    readonly path: string;
+    readonly source: string;
+}, 
+/**
+ * What the host has already dealt with (#328). Evaluation is unchanged and
+ * the model is untouched: this decides only what the pane draws, because a
+ * question set aside in the host's own product should not be asked again by
+ * a pane embedded in it.
+ */
+dismissed?: readonly DismissedQuestion[]) => VisualInterrogationOverlay | undefined;
 /**
  * Rebuilds the shared editor workspace from one successful compile.
  *
  * The caller owns metadata which cannot be inferred from a graph (authority,
  * source revisions, layouts, and initial view); this helper owns all derived
- * canvas, vocabulary, and view-count arithmetic.
+ * canvas, vocabulary, view-count, and interrogation arithmetic. `catalogue`
+ * is the question catalogue's bytes — this module cannot read files, so
+ * whoever can hands them over; omitting it ships a model with no overlay.
  */
 export declare const renderedWorkspaceOf: (compiled: {
     readonly graph: SemanticGraph;
     readonly profileContext: ResolvedProfileContext;
-}, views: readonly VisualViewSummary[], metadata: Omit<VisualRenderedModel, "graph" | "vocabulary">) => {
+}, views: readonly VisualViewSummary[], metadata: Omit<VisualRenderedModel, "graph" | "vocabulary" | "interrogation">, catalogue?: {
+    readonly path: string;
+    readonly source: string;
+}, dismissed?: readonly DismissedQuestion[]) => {
     readonly model: VisualRenderedModel;
     readonly views: readonly VisualViewSummary[];
 };

package/dist/adapters/visual/workspace-model.js

@@ -6,6 +6,7 @@ import { projectGraphForCanvas } from "../../graph-projection.js";
 import { DEFAULT_PROJECTION_DIRECTORY } from "./view-identity.js";
 import { evaluateProjection, explainProjection } from "../../projection.js";
 import { kindLabelOf } from "../../kind-label.js";
+import { evaluateCatalogue, loadQuestionCatalogue, } from "../../interrogate-command.js";
 /**
  * What a workspace looks like to the editor, however the editor is being run
  * (#252).
@@ -45,18 +46,76 @@ export const kindOptionsOf = (lineages) => [...lineages.keys()].map((id) => ({
  * them would read as five, and the reviewer counting boxes would find three.
  */
 export const conceptCountOf = (graph, query, profileContext) => evaluateProjection(graph, adHoc(query), profileContext).subjects.filter(({ type }) => type === "concept").length;
+export const interrogationOverlayOf = (compiled, catalogue, 
+/**
+ * What the host has already dealt with (#328). Evaluation is unchanged and
+ * the model is untouched: this decides only what the pane draws, because a
+ * question set aside in the host's own product should not be asked again by
+ * a pane embedded in it.
+ */
+dismissed = []) => {
+    const loaded = loadQuestionCatalogue(catalogue);
+    if (!loaded.ok)
+        return undefined;
+    const report = evaluateCatalogue(loaded.catalogue, compiled.graph, compiled.profileContext);
+    const dismissedEverywhere = new Set(dismissed
+        .filter(({ subject }) => subject === undefined)
+        .map(({ questionId }) => questionId));
+    const dismissedForSubject = new Set(dismissed
+        .filter(({ subject }) => subject !== undefined)
+        .map(({ questionId, subject }) => `${questionId}\u0000${subject}`));
+    const workspace = [];
+    const subjects = {};
+    for (const wave of report.waves) {
+        for (const question of wave.questions) {
+            if (!question.open)
+                continue;
+            if (dismissedEverywhere.has(question.id))
+                continue;
+            const base = {
+                questionId: question.id,
+                authority: question.authority,
+                ...(question.since === undefined ? {} : { since: question.since }),
+            };
+            if (question.subjects === undefined) {
+                workspace.push({ ...base, question: question.question });
+                continue;
+            }
+            for (const subject of question.subjects) {
+                if (dismissedForSubject.has(`${question.id}\u0000${subject.id}`)) {
+                    continue;
+                }
+                (subjects[subject.id] ??= []).push({
+                    ...base,
+                    question: subject.question,
+                });
+            }
+        }
+    }
+    return {
+        catalogue: report.catalogue,
+        semantics: report.semantics,
+        workspace,
+        subjects,
+    };
+};
 /**
  * Rebuilds the shared editor workspace from one successful compile.
  *
  * The caller owns metadata which cannot be inferred from a graph (authority,
  * source revisions, layouts, and initial view); this helper owns all derived
- * canvas, vocabulary, and view-count arithmetic.
+ * canvas, vocabulary, view-count, and interrogation arithmetic. `catalogue`
+ * is the question catalogue's bytes — this module cannot read files, so
+ * whoever can hands them over; omitting it ships a model with no overlay.
  */
-export const renderedWorkspaceOf = (compiled, views, metadata) => {
+export const renderedWorkspaceOf = (compiled, views, metadata, catalogue, dismissed) => {
     const refreshedViews = views.map((view) => ({
         ...view,
         subjectCount: conceptCountOf(compiled.graph, view.query, compiled.profileContext),
     }));
+    const interrogation = catalogue === undefined
+        ? undefined
+        : interrogationOverlayOf(compiled, catalogue, dismissed);
     return {
         model: {
             ...metadata,
@@ -65,6 +124,7 @@ export const renderedWorkspaceOf = (compiled, views, metadata) => {
                 conceptKinds: kindOptionsOf(compiled.profileContext.conceptKindLineages),
                 relationshipKinds: kindOptionsOf(compiled.profileContext.relationshipKindLineages),
             },
+            ...(interrogation === undefined ? {} : { interrogation }),
         },
         views: refreshedViews,
     };