Add guide lines feature

[jsjgdh]

Adds feature for guide lines that can be dragged from the rulers to help with alignment .closes #2601
image of guide lines:

[0HyperCube]

It still looks strange when rotating a document with guides in:

rotating_document_with_guide.mp4

Also the snapping doesn't work when the document is rotated.

[0HyperCube]

Seems to work well; I have a few suggestions for the code structure. I won't comment on the JS changes.

Please mark the PR as «Ready to review» when you are happy with it.

[Keavon]

!build

[github-actions]

📦 Build Complete for f2cb67b
https://c16f0eb0.graphite.pages.dev

[Keavon]

Some of the ~750 lines of code is for snapping, right? At least when I glanced over it last, I thought I saw that. In testing this build link, I am not seeing any snapping to objects in the document.

The "Move Guide" hint should be removed since the user is already dragging the guide.

More review to follow when I have time. My previously stated concern that the line count seems way too high still applies and I'm hesitant to merge it before that can be either resolved or justified to me as to why it's about double the number of lines I would expect from this feature.

[0HyperCube]

The snapping changes are from the object to the guide. For example when drawing a rectangle:

I suppose it could also be useful to snap the origin of the guide when you are placing it (to match inkscape's features).

I'm not sure how you have determined that exactly 376 lines is the required number to implement this feature? However I guess I will defer to your superior knowledge on this matter.

[0HyperCube]

Please use document.metadata().transform_to_viewport directly. There should be no need to use the calculate_offset_transform anywhere in your code since it is already cached.

[cubic-dev-ai]

2 issues found across 7 files (changes from recent commits).

Confidence score: 3/5

• In frontend/src/utility-functions/colors.ts, the new guard checks Gradient.color instead of the backend’s Gradient.stops.color, so valid gradient ramps can be treated as None and silently dropped, causing incorrect or missing gradient rendering — restore the .stops path check or normalize the payload shape before validation.
• In frontend/src/components/widgets/inputs/SpectrumInput.svelte, midpoint diamonds are now shown for stepped interpolation even though midpoint bias has no effect there, which can mislead users into editing a control that cannot change output — reintroduce the stepped-interpolation guard so midpoint handles only appear for interpolations that support them.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="frontend/src/components/widgets/inputs/SpectrumInput.svelte">

<violation number="1" location="frontend/src/components/widgets/inputs/SpectrumInput.svelte:369">
P2: Stepped gradients now show draggable midpoint diamonds even though stepped interpolation has no midpoint bias, exposing a control that cannot affect the rendered gradient. Preserve the stepped-interpolation guard when calculating `midpointPositions`.</violation>
</file>

<file name="frontend/src/utility-functions/colors.ts">

<violation number="1" location="frontend/src/utility-functions/colors.ts:185">
P1: Existing gradient values are discarded as `None` because the backend sends `Gradient.stops.color`, but this new guard looks for `Gradient.color`; keeping the `.stops` boundary (or explicitly normalizing the ramp before these helpers) preserves gradient swatches and contrast calculations.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>