docs: record the five Phase 8 prerequisites, and report contributions

Bring the living documentation in line with what the five passes actually
shipped, and correct the claims they superseded rather than leaving them to
mislead: the module UI context is six members, not five; module styling is
compiled CSS, not inline objects only; the strict manifest is version 7.

Also close a silent failure the new contribution mechanism introduces. A
contribution whose target capability nobody provides — or whose provider moved
outside its declared range — is not published, and the manifest is valid and
the artifact exists, so an operator sees a screen that renders nothing with no
error anywhere. `pnpm modules:validate` now lists each declared contribution
with its capability and range and says whether a compatible provider is
installed, and Doctor's discovery check reports the same per module. Both
derive from the publication registry the API serves from, so neither can
disagree with what a running platform would actually publish.

Co-Authored-By: Claude Opus 5 <[email protected]>

core/src/cli/validate-modules.ts

@@ -3,6 +3,7 @@ import path from "node:path";
 import { PermissionRegistryError } from "../authorization/index.js";
 import {
   composePlatformPermissionRegistry,
+  createModuleUiPublicationRegistry,
   discoverModuleSchemas,
   ModuleDiscoveryError,
   ModulePermissionCompositionError,
@@ -45,11 +46,32 @@ async function main(): Promise<void> {
     return;
   }
 
+  // Built from the same registry the API publishes from, so this command can never disagree with
+  // what a running platform would actually serve. A contribution whose target capability nobody
+  // provides — or whose provider moved outside its declared range — is otherwise silent: the
+  // manifest is valid, the artifact exists, and nothing renders (ADR 0041).
+  const publication = createModuleUiPublicationRegistry(modules);
+  const compatibleContributions = new Set(
+    publication
+      .listContributions()
+      .map((contribution) => `${contribution.moduleId}\u0000${contribution.contributionId}`),
+  );
+
   console.log(
     `Module validation passed (${modules.length} modules, ${schemaAggregate.tables.length} tables):`,
   );
   for (const discoveredModule of modules) {
     console.log(`- ${discoveredModule.manifest.id}@${discoveredModule.manifest.version}`);
+    for (const contribution of discoveredModule.contributions) {
+      const resolved = compatibleContributions.has(
+        `${discoveredModule.manifest.id}\u0000${contribution.id}`,
+      );
+      console.log(
+        `  contributes ${contribution.id}@${contribution.version} to ${contribution.capability} ${contribution.capabilityRange} — ${
+          resolved ? "compatible provider installed" : "no compatible provider installed"
+        }`,
+      );
+    }
   }
 }
 

core/src/diagnostics/doctor.ts

@@ -57,6 +57,7 @@ import {
   createModuleConfigurationStore,
   createModuleLifecycleDatabase,
   createModuleLifecycleStore,
+  createModuleUiPublicationRegistry,
   type DiscoveredModule,
   discoverModuleSchemas,
   discoverModules,
@@ -316,7 +317,26 @@ function publishReport(checks: readonly DoctorCheck[]): DoctorReport {
   return Object.freeze({ checks: frozenChecks, result: deriveDoctorResult(frozenChecks) });
 }
 
+/**
+ * One line per installed module, plus — for a module that declares browser contributions (ADR 0041)
+ * — how many of them have a compatible provider among the installed set.
+ *
+ * Worth reporting because the failure it names is otherwise silent: a contribution whose target
+ * capability nobody provides, or whose provider moved outside its declared range, is simply not
+ * published, and an operator sees a screen that renders nothing with no error anywhere. The counts
+ * are derived from the same publication registry the API serves from, so this can never disagree
+ * with what the running platform would actually publish.
+ *
+ * Static only, like every other Doctor check: it reports what the *manifests* support and never
+ * claims a module is running. Enablement and dependency blocking are the lifecycle check's job.
+ */
 function safeModuleDetails(modules: readonly DiscoveredModule[]): readonly string[] {
+  const publication = createModuleUiPublicationRegistry(modules);
+  const compatible = new Set(
+    publication
+      .listContributions()
+      .map((contribution) => `${contribution.moduleId}\u0000${contribution.contributionId}`),
+  );
   return modules.map((module) => {
     const id = module.manifest.id;
     const version = module.manifest.version;
@@ -326,7 +346,16 @@ function safeModuleDetails(modules: readonly DiscoveredModule[]): readonly strin
     ) {
       throw new TypeError("Unsafe module diagnostic value.");
     }
-    return `${id} ${version}`;
+    const declared = module.contributions.length;
+    if (declared === 0) {
+      return `${id} ${version}`;
+    }
+    const resolved = module.contributions.filter((contribution) =>
+      compatible.has(`${id}\u0000${contribution.id}`),
+    ).length;
+    return `${id} ${version} · ${declared} browser contribution${
+      declared === 1 ? "" : "s"
+    } (${resolved} with a compatible provider)`;
   });
 }