Repository navigation
Conversation
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.
…kens, responsive contract and production overrides Linear: STU-371 - Add docs/design/ README, SOURCE-MANIFEST, TOKENS, RESPONSIVE, BEHAVIOR-OVERRIDES, REFERENCE and TRACEABILITY. - Map hero -> primary app surface; journey -> workflow guidance; account / monetisation -> separate product surfaces. - Exclude launcher chrome, before-* variants, hero-1, outro studies, fixed-film walkthrough and MILESTONE-PLAN from production routes. - Document 13 local suggestion patterns, token table, font paths and the 1920x1080 presentation-only fit scaling caveat. - Record production overrides for runs counter, tier limits/pricing, suggestions, and unsupported backend capabilities.
Owner
Author
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
…can reach a class transitively
… scratch-graph approximation
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.`, | ||
| ); |
Contributor
There was a problem hiding this comment.
This creates a notice for every unrepresentable dependency before checking which classes will compile. If a deployment contains only dart:-only classes, or every class is skipped, app.js still displays “Verified approximately” even though no class was compiled against the reduced package graph. This gives users an inaccurate verification status.
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/customCodeVerification.js
Line: 217-220
Comment:
**Approximation warning is inaccurate**
This creates a notice for every unrepresentable dependency before checking which classes will compile. If a deployment contains only `dart:`-only classes, or every class is skipped, `app.js` still displays “Verified approximately” even though no class was compiled against the reduced package graph. This gives users an inaccurate verification status.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
Owner
Author
|
@greptileai — all findings from the previous review have been addressed (see new commits). Please re-review this PR. |
Owner
Author
|
Closing: this branch is already fully contained in |
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.
Closes STU-371.
What this PR does
Adds a versioned design-source record under
docs/design/for the Updated UI/UX milestone, keeping implementation work traceable and avoiding stale handoff assumptions.Added files
docs/design/README.md— source-to-surface map and document indexdocs/design/SOURCE-MANIFEST.json— SHA-256 manifest of canonical handoff filesdocs/design/TOKENS-AND-ASSETS.md— hero tokens, fonts, assets, and the 13 local suggestion patternsdocs/design/RESPONSIVE.md— nine named viewports, reflow expectations, and thetranslate(67px,-304px)caveatdocs/design/BEHAVIOR-OVERRIDES.md— production overrides for runs counter, tier limits/pricing, suggestions, and unsupported capabilitiesdocs/design/REFERENCE.md— how workers access the read-only handoff folder without copying the archivedocs/design/TRACEABILITY.md— requirement → milestone ticket → reference surface mappingVerification
npm test— 274/274 passing.npm run build— production bundle built successfully.The PR appears safe to merge, with one non-blocking accuracy issue remaining in the existing verification-status thread.
Fix with agent prompt
Summary
This PR records the canonical redesign sources and production behavior overrides, while also strengthening custom-code verification, deployment safeguards, CI, and bundle leak detection. Greptile automatically discovered a related ticket that helped explain the purpose of this PR: preserve reproducible design-source provenance, document responsive and production overrides, and map requirements to milestone surfaces.
Reviews (4) · Last reviewed commit: "fix: scope the verification skip to dire..."