Skip to content

STU-373: Apply exported typography, color, spacing and motion tokens - #78

Closed
sgardoll wants to merge 11 commits into
mainfrom
sgardoll/stu-373-apply-the-exported-typography-color-spacing-and-motion
Closed

sgardoll wants to merge 11 commits into
mainfrom
sgardoll/stu-373-apply-the-exported-typography-color-spacing-and-motion

Conversation

@sgardoll

@sgardoll sgardoll commented Sep 22, 2026 •

Copy link
Copy Markdown
Owner

Closes STU-373.

What this PR does

  • Extracts the canonical design token set into a shipping stylesheet src/designTokens.css (surfaces/ink, coral accent, state colors, type scale, weights, radii, shadows, spacing, motion, reduced-motion and focus defaults).
  • Links the stylesheet from index.html, removes the legacy inline :root except --sidebar-w, and migrates legacy CSS variable references to the new tokens.
  • Reuses the existing /fonts/Delight-VF.ttf asset and the DM Mono Google Fonts link.
  • Leaves app.js untouched because it contains no affected custom-property references.

Verification

  • npm test — 274/274 passing.
  • npm run build — production bundle built successfully, Delight-VF bundled.
  • Playwright checks against the preview build confirmed all required :root tokens are defined, the font loads, body colors resolve to the canonical OKLCH values, and reduced motion suppresses the spinner animation.
  • Reference screenshots captured at 1440×900 and 360×800 (stored locally in the worktree).

Intentional deviations

  • Some hardcoded blue/purple hex values remain in decorative walkthrough/pricing-modal illustrations and component states that were not part of the migrated token set; those will be reconciled by their owning surface issues to avoid a blanket refactor.

RetriggerConfidence Score: 5/5

The PR appears safe to merge, with only the previously reported non-blocking verification-coverage wording issue still outstanding.

Fix All in DevinFindings

  1. P2 Approximation notice overstates coverage ▶
Fix with agent prompt
### Issue 1
src/customCodeVerification.js:217-220
The notice is created from every unrepresentable dependency before the code checks which classes are compiled. As a result, a deployment containing only `dart:` imports-or one where every class is skipped-still appears as “Verified approximately,” even though no compiled class used the reduced package graph and possibly no class was verified. This gives users an inaccurate account of verification coverage. Only emit this notice when a compiled source has a `package:` import affected by the reduced graph.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

This PR centralizes the exported design system into a shipping stylesheet, migrates legacy CSS variables, adds reduced-motion and focus defaults, and expands deployment verification and CI safeguards.

  • Adds canonical typography, color, spacing, radius, shadow, and motion tokens in src/designTokens.css.
  • Updates the application and generated distribution assets to consume the new tokens.
  • Improves dependency-source classification and bounds SDK package processing.
  • Adds CI, deployment guard coverage, and production bundle leak scanning.

Reviews (4) · Last reviewed commit: "fix: scope the verification skip to dire..."

STU-368. Which packages the Flutter SDK supplies was decided by a
hand-maintained name list kept in three places, and flutter_web_plugins was in
none of them. Every project declaring it - which is every web-enabled project
with a plugin - read it as a dependency that could not be reproduced, and the
deploy was refused for a package most of its classes never imported.

The project's own pubspec already says where each package comes from; the
parser read those lines and threw them away. It now returns them as
sourceKey/sourceValue, so the classification is exact and cannot fall behind
the SDK:

  sdk:                            -> the Flutter SDK, reproduced from the name
  a nested version:               -> a constraint written on its own line
  git: / path: / nested hosted:   -> not expressible in the manifest

SDK_DEPENDENCIES is gone. The runner's allowedSdkPackages is gone too - it
independently refused the same deploy with 'Unsupported SDK package'. That
allowlist was also the only validation of an sdkPackages entry, so the package
name pattern now does that job; without the swap a caller-supplied name would
reach the generated pubspec unchecked. The runner still writes 'sdk: flutter'
itself, so that value never comes from a caller.

Refusal is now scoped per class, to that class's own imports, so one git: entry
no longer leaves an entire deploy uncompiled.

The accept/warn split already existed and is unchanged: a real analyzer error
refuses with 422, and a class that could not be compiled is pushed with its
warning logged before the provisioning request.

Corrects DEPLOYMENT.md, which still described the scaffolding-closure
compilation that reverting a1238f0 removed, and still claimed that nothing
unverified is deployed.

Verified: 274/274 tests, deploy guard 9/9, proxies 30/30, build clean, dart
analyze on the runner reports no issues.
- Add src/designTokens.css as the single shipping token stylesheet, extracted
  from the canonical custom-code-connect-hero.html :root token set.
- Link the stylesheet from index.html; reuse existing /fonts/Delight-VF.ttf
  and DM Mono Google Fonts path.
- Replace the legacy inline :root in index.html with only the layout
  constant --sidebar-w, preserved until its owning shell change.
- Migrate legacy variable references to new tokens:
  --main-bg -> --bg, --navy -> --fg, --label -> --muted, --sublabel -> --muted-2,
  --input-bg -> --surface-sunken, --input-border -> --border,
  --badge-bg -> --accent-soft, --badge-text -> --accent,
  --glow-color -> --accent-soft.
- Centralize :focus-visible and prefers-reduced-motion defaults in the token
  stylesheet and remove redundant local reduced-motion rules.
- No generation/deploy code changed; app.js has no affected CSS var refs.
@sgardoll

Copy link
Copy Markdown
Owner Author

@greptileai

Comment thread src/pubspecSync.js Resolved
Comment thread cloud-run/ffai-runner/bin/server.dart Resolved
…can reach a class transitively

(cherry picked from commit 9d338ad)
…pe in a Set

The public deploy route accepted an unbounded sdkPackages array and deduped
it with repeated result.contains scans, so an unauthenticated caller could
submit a very large list for quadratic parsing work and an equally large
scratch pubspec. Cap the list at maxDependenciesPerRequest (200) - the same
per-request budget the dependency maps use, since every accepted name is
emitted as a dependencies: entry in the generated pubspec - and reject with
the same 'Too many entries in verification...' error style. Deduplicate via
a Set instead, keeping insertion order and the List<String> contract.

Also rebuild dist/ so the committed output carries this branch's token
changes (new CSS bundle beside the unchanged JS).
Comment thread src/customCodeVerification.js Resolved
… scratch-graph approximation

(cherry picked from commit e300b76)
Comment on lines +217 to +220
const approximate = unrepresentable.map(
(name) =>
`Your project declares ${name} from a source that cannot be reproduced outside it, so the pre-deploy compile check runs against a scratch package graph that omits ${name}. Classes that do not import ${name} directly are still checked, but against that reduced graph, so their transitive package resolution may differ from your project's and the check is approximate for them.`,
);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Approximation notice overstates coverage

The notice is created from every unrepresentable dependency before the code checks which classes are compiled. As a result, a deployment containing only dart: imports—or one where every class is skipped—still appears as “Verified approximately,” even though no compiled class used the reduced package graph and possibly no class was verified. This gives users an inaccurate account of verification coverage. Only emit this notice when a compiled source has a package: import affected by the reduced graph.

Prompt To Fix With AI
This is a comment left during a code review.
Path: src/customCodeVerification.js
Line: 217-220

Comment:
**Approximation notice overstates coverage**

The notice is created from every unrepresentable dependency before the code checks which classes are compiled. As a result, a deployment containing only `dart:` imports—or one where every class is skipped—still appears as “Verified approximately,” even though no compiled class used the reduced package graph and possibly no class was verified. This gives users an inaccurate account of verification coverage. Only emit this notice when a compiled source has a `package:` import affected by the reduced graph.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Fix in Claude Code Fix in Codex Fix in Devin

@sgardoll

Copy link
Copy Markdown
Owner Author

@greptileai — all findings from the previous review have been addressed (see new commits). Please re-review this PR.

@sgardoll

Copy link
Copy Markdown
Owner Author

Closing: this branch is already fully contained in milestone/stu-implement-updated-ui-ux, merged during the earlier integration run as f9d9e62 (STU-373). GitHub refuses to retarget this PR to the milestone branch for that exact reason — there are no new commits between the two. The work therefore ships with the milestone → main PR and this PR no longer corresponds to anything unmerged. Nothing is lost; the commits remain in history.

@sgardoll sgardoll closed this Sep 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant