Repository navigation
Document floating surfaces in the design catalog - #135
Merged
Merged
Conversation
Signed-off-by: Carl <c217fe6b9d958f41c3a5e030dccc7f626775a923089cb6491305eade75ea1f1b@buzz.block.builderlab.xyz>
morgmart
marked this pull request as ready for review
September 22, 2026 16:07
morgmart
requested review from
a team,
comp615 and
wesbillman
as code owners
September 22, 2026 16:07
wesbillman
reviewed
Sep 22, 2026
wesbillman
left a comment
Collaborator
There was a problem hiding this comment.
Carl, an automated reviewer, commenting via Wes’s GitHub account.
Review clear
No actionable blockers found at 9dbd7f73e9d372a79b32d87c37dcbcac98f00028 against base e9717dda50eb25e81e0edad30b5d0500a052b591.
- The four-file change stays catalog-only: the route, Foundations link, and existing reload/isolation traversal agree. Component links resolve to existing registry entries; the page reuses the viewer’s theme owner and real shared controls.
- The documented
floating-surfaceroles match the shared CSS and PreviewCard/Select consumers. The page accurately distinguishespopover-surfaceexceptions without migrating production behavior or introducing a new styling owner. - Validation: read-only pinned-source review on Blox, with an independent contract review integrated. Existing exact-head required CI is successful. No PR code or tests were executed by this review; the standalone catalog browser run and visual acceptance were not independently reproduced. Existing browser assertions remain intact, with no test cases added or removed.
wesbillman
approved these changes
Sep 22, 2026
wpfleger96
added a commit
that referenced
this pull request
Nov 6, 2026
…#2649) Moves values that only make sense for one distributor out of the open-source tree and into build settings, and removes internal references from docs, tests and fixtures. **Merge order:** this PR and [squareup/buzz-releases#135](squareup/buzz-releases#135) depend on each other and merge together: this PR first, then #135 right after, with no release build in between. #135 sets the new build inputs; without them a release build loses the Git access rule and the Apps control plane. #135 also checks that the built app contains both values, so it fails on any buzz-app commit from before this PR. ## Build settings - **`BUZZ_BUILD_REPOSITORY_ACCESS`** replaces the hardcoded `squareup` rule in `crates/plugin-manager/src/access.rs`. It holds JSON in the `repository-access.json` schema and is compiled in as the default rules. The parser now lives in `access/schema.rs` and is shared with `build.rs`, so a value that isn't valid, has no rules or has an unusable rule fails the build. The build emits the value as compact JSON, so a pretty-printed value reaches the runtime whole. Unset means no default rules. Runtime file behavior is unchanged. - **`BUZZ_BUILDERLAB_APPS_CONTROL_PLANE`** names the Apps control plane for the build's own login origin. Rust (`apps_control_plane`) and TypeScript (`controlPlane`, plus the dev broker in `vite.config.ts`) both read it from the same sources: the process environment, then `.env.local`. Vite mode files such as `.env.production` are not read. Both sides require an HTTPS origin and a login origin. The private tenant entries (production and staging) are removed from both public tables. The native FI forwarder's Apps mode (`src-tauri/src/federated_identity/access.rs`) resolves its control plane through the same `apps_control_plane`, and in an FI build `BUZZ_BUILDERLAB_ORIGIN` is the descriptor's identity origin, so the setting applies to FI sign-in too. - `release.yml` no longer compiles one private community into the external-MCP and owner-access allowlists (`BUZZ_EXTERNAL_MCP_COMMUNITIES`, `BUZZ_OWNER_MCP_COMMUNITIES`) or the workflow-restriction list (`BUZZ_WORKFLOW_RESTRICTED_COMMUNITIES`). Builds that want them set their own origins, and the docs and workflow-authorization test use example communities. - `communityName` drops its hard-coded list of hosted suffixes. An unnamed `<name>.communities.<domain>` host shows as `<name>` on any domain, and any other host shows in full. ## Cleanup - Docs: bb-block rollout text, private signing-infrastructure link, IAM role and bucket names, internal release-repo inventory, private backend and security-plugin links (including the security-plugin link in `docs/releases.md`), and design-system source links. The design system describes its values in its own terms instead of naming an outside design reference. - Tests and fixtures (including the federated-identity fixtures that came in with main): private hosts, org and repo names, and the SSH user are replaced with example values. A ticket key is dropped. - Internal work logs are removed (`docs/archive/hardening-*`, and the matching parts of `docs/status.md` and `docs/inbox.md`). - `AGENTS.md`: the personal acceptance-setup section is removed. A new "Open-source boundary" section lists what must not be committed and the build settings to use instead. It also says the rule covers functionality, not only identifiers: features must be generic, Block-only functionality belongs in a privately kept plugin, and host changes for such plugins must be documented, inert, general-purpose extension points. ## Validation - `cargo test -p buzzodz-plugins --lib`: 80 passed. - A build with `BUZZ_BUILD_REPOSITORY_ACCESS` set to the buzz-releases value resolves `https://github.com/squareup/x.git` to the same SSH URL and agent socket as the old built-in rule (`buzzodz plugin access`). An invalid value fails the build. - `build_config` tests cover compact emission of pretty-printed JSON, and the control plane from process and `.env.local` but not from a mode file. `browser-host/vite-config.test.mjs` covers the same frontend cases plus a rejected non-origin value. A `buzzodz` built with pretty-printed JSON resolves its rule at runtime (exit 0). - `cargo test -p buzzodz-plugins` and the `federated_identity` tests in `src-tauri` pass. - Every changed unit-test file passes when run on its own. Related: [squareup/buzz-releases#135](squareup/buzz-releases#135), [block/buzz#9114](block/buzz#9114) --------- Signed-off-by: Will Pfleger <wpfleger@block.xyz> Co-authored-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this does
Adds Floating surfaces to the design catalog’s Foundations section, beside Elevation and Glass. It gives the design-system owner a place to inspect the existing card recipe, try the real Preview Card and Select, and see where adoption still differs.
This is catalog-only: no enforcement, popup migration, shared styling changes, or composer integration.
Why it matters
The shared appearance already exists but was only visible through individual components. This page makes its background, border, corners, and shadow understandable together without claiming every floating surface already uses it.
How it works
The page renders the existing shared recipe and components, links to their catalog entries, and documents the separate popup recipe and remaining exceptions. The recipe stays in the shared design system; nothing moves and no new product component is introduced.
Open Foundations → Floating surfaces in the standalone catalog. Hover over the preview example, open the notification dropdown, and switch themes.
Verification
e9717dd; subsequent edits only clarified prose.9dbd7f7, including design types and guards; independent review findings were addressed.Screenshots