Put accepted brand assets where they are used
After a brand is accepted, distribute its files and references to the application’s participating front ends. This turns an approved asset set into the images each serving surface can actually load.
Example — Update a logo across the public site and docs
The accepted logo is copied to each site’s asset location, with icon and header references reconciled to the files that were placed.
For engineers
The creation journey propagates on its own: accepting a mark, and the foundation step composing a surface that receives it, both run the same propagation. Run the command from the application root when you replace the accepted set by hand:
wildo brand propagate --dry-run
wildo brand propagate
wildo brand propagate --only website-public
The command reads the accepted specifications asset set, not generation staging. The dry run prints the plan without writing; --only selects a destination key. It does not generate or accept a logo.
Understand what propagation changes
Website and documentation destinations place public files and update their specific icon or logo references. The runtime-configuration destination writes the generated projection consumed by application configuration; it is not simply another image folder. Destination handlers use the asset’s actual format and the common public path mapping. Each surface is located from the services wildo.saas.config.ts declares, so a front end whose folder is not the conventional name still receives the brand.
Inspect the plan, apply it, then verify the target origin can serve the referenced files. Copying into the repository is distinct from deploying that repository. Do not hand-edit several surfaces to compete with the accepted source; add a supported destination when a new surface needs an explicit propagation path.