Dynamic Manifest Registry

Status: proposed
Deciders: Platform Team
Date: 2026-06-29
Parent: 0001 — Adopt WhiskerPlatform over rwe-core

Technical Story: Module registration — static host files vs manifest pipeline

Context and Problem Statement

A module’s presence in the host (navigation, widgets, pages, iframe URLs, federation remotes) must be discoverable by whisker-host without rebuilding the host for every module change.

rwe-core encodes registration in hand-edited TypeScript:

app-registry.ts — federated pages
widget-registry.ts — dashboard widgets
apps.json + retail-launch-pad/ — iframe consumers

WhiskerPlatform encodes registration in each module’s module-manifest.json, published through:

module CI → S3 → Lambda (validate + admin merge) → DynamoDB
         → BFF /manifests/v1 → host runtime
         → sync-deployed-registry.yml → host build-time loader

This ADR decides which registry model Whisker adopts. It is a child of 0001.

Decision Drivers

Single source of truth per module — Registration lives in the module repo, not the host repo.
Structural validation — Invalid manifests fail before production registry state.
Runtime + build-time consumers — Browser loads from BFF; host CI regenerates federation artifacts from the same registry.
Admin fields survive redeploy — enabled, allowedPersonas must not be wiped when a module republishes its bundle.
Iframe + federation unity — One schema, one ingest path.

Considered Options

Option A — Static host registries (rwe-core)

Module teams PR against rwe-host registry files. Host build wires federation remotes from those files.

Option B — Dynamic manifest pipeline (WhiskerPlatform)

Per-module manifest; automated ingest; DynamoDB; BFF read path; host sync workflow for federation loader. Federation and iframe consumers use the same manifest path.

Pros and Cons

Option A

Good: no Lambda/DynamoDB/DLQ; TypeScript compile checks in host repo.
Bad: every registration change is a host PR; iframe URLs and remotes drift from module repos; no admin merge at ingest.

Option B

Good: zero host PRs for registration; Zod at scaffold/commit/CI/Lambda; admin-aware mergeManifestForUpsert; dynamic iframe origin lists.
Bad: /manifests/v1 public-read dependency for sync + local dev; async gap merge→visible; DLQ ops; schema cannot validate componentPath or live iframe reachability.

Decision Outcome

Chosen option: Option B — dynamic manifest pipeline.

See Manifest pipeline for mechanism detail.

Positive Consequences

Module manifest is versioned with module code.
Ingest rejects structurally invalid manifests.
Host and browser read the same registry via BFF.

Negative Consequences

Platform owns Lambda, DynamoDB, DLQ, S3 notifications.
whisker-bff extraction from sim-bff still pending.
Publisher → Slack notification not wired (visibility gap).