Self-Service Module Automation

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

Technical Story: Module team automation — scaffolding, CI, local dev, compliance

Context and Problem Statement

Registering a module is not only where the registry lives (0002) — it is what work a module team must do to go from zero to production.

rwe-core provides:

A host monorepo with pnpm dev for host + shell + example demo
No scaffolder for real modules — teams copy rwe-demo-app or an external repo, hand-wire Vite federation, shared deps, and Jenkins
Host PRs for registry entries, routes, iframe wrappers
No doctor, no manifest pre-commit hook, no contract diff tooling

WhiskerPlatform provides:

@nike/create-whisker / thundercats create module — repo, manifest, federation config, Jenkinsfile, husky, .agents/
@nike/whisker-module-kit — whisker dev, generate-manifest, validate-manifest, doctor, pre-commit/post-commit
Module CI → S3 manifest upload → repository_dispatch to host sync
whisker-contract.json + whisker update-check for host drift

This ADR decides whether self-service automation for module teams is a deliberate platform investment vs continuing rwe-core’s DIY model.

Decision Drivers

Time-to-first-PR for a new squad without host-team pairing
Repeatability — every module repo looks the same at day zero
Compliance without host gate — husky + doctor + (planned) devkit instead of host PR review
Local dev orchestration — whisker dev wires host + local module
Honest limit — automation does not remove need to understand manifest schema

Considered Options

Option A — DIY module setup (rwe-core model)

Document patterns; module teams copy example repos and open host PRs.

Option B — Platform kit + scaffolder (WhiskerPlatform)

Standard scaffold, CLI orchestration, CI templates, notify-host workflow.

Option C — Kit without scaffolder

Publish manifest schema and CI snippets only; no create command.

Pros and Cons

Option A

Good: no Artifactory kit releases to maintain; minimal platform scope.
Bad: high variance across module repos; host PRs remain; no pre-commit manifest enforcement; real modules need two repos with manual wiring.

Option B

Good: thundercats create module + auto thundercats init; whisker dev orchestrates host prep, local remote, browser-sync; husky catches bad manifests; thundercats audit / thundercats update for agent surface drift.
Bad: kit + CLI release cadence; Node 24+ floor; first whisker dev may clone host; learning curve for manifest schema vs three registry files.

Option C

Good: lighter platform surface than full scaffolder.
Bad: squads still copy-paste; drift between repos; loses main onboarding win.

Decision Outcome

Chosen option: Option B — platform kit + scaffolder.

Module teams are the primary consumers of @nike/whisker-module-kit and @nike/create-whisker (via thundercats create). Host team maintains the script contract (whisker:prep, whisker:rebuild-loader, whisker:restore) — not per-module host edits.

Not claimed as complete today:

Devkit panel (port 3009) — design only; doctor runs real checks
./e2e / whiskerTest fixture export in module-kit — planned, not started; module teams write plain @playwright/test specs today
@nike/whisker-service-kit — runtime is feature-complete but excluded from the initial Artifactory pilot publish

Positive Consequences

New modules land with CI, manifest hooks, and notify-host workflow.
Registration changes do not require host-team code review.
whisker doctor gives remediation hints before whisker dev.

Negative Consequences

Platform must publish and support kit versions on Artifactory.
Squads must adopt manifest-driven workflow — not optional if on Whisker.
rwe-core’s single-repo demo convenience is not replicated for real modules.