XCS Format Support

This plan comes first because it is the instrument for the other three. Without it, each of them is a claim.

What the verifier does today

XCS Module Validation runs 16 checks in a single ungrouped list: PROJECT Init, TEXT Baking, RECT / SCORE, CIRCLE / ENGRAVE, BITMAP / COLOR, IMAGE Passthrough, Closed Filled Path, OPEN PATH (Spiral), Compound Vectors, Compound (Reversed), Boundary Frame, Capsule Stroke, Arc Sampling, Color Fidelity, Scale Stress and RUNTIME CRASH.

7 of those already measure rendered geometry rather than structure. verifyGeometry() reads the rendered SVG's own getBBox() and compares it against expected millimetres, at a 0.3 mm tolerance, for CLOSED_PATH, SPIRAL, COMPOUND, COMPOUND_REV, FRAME, CAPSULE_STROKE and ARC_SAMPLE. Its comment records why it exists: structural assertions like !!dPath never caught the double-translate placement bug, because _renderPath() applies its own translate on top of whatever dPath it is given.

Three round-trip exports exist already — Test Export (PNG + XCS), Test Export (Stress) for the 1000-item project, and Text Cal Export. They are buttons a person remembers to press, not tests with a recorded expected result.

The restructure

1. Put the existing 16 into a Unit Tests tab. Unchanged in content and order. They assert that the file is structurally correct.
2. Add a Render Tests tab. Each entry is a scenario rather than an assertion: it draws something, renders it both ways, compares, and offers the .xcs for Creative Space.
3. Its first entry is Geometry Baseline — the seven existing verifyGeometry() checks, moved across intact. They are the baseline every later entry is measured against, and moving rather than rewriting them keeps that baseline honest.
4. Give every render entry the same four parts: what it draws, the automated comparison and its tolerance, an export button, and the expected observation in Creative Space written down before anyone opens it. A round trip with no recorded expectation proves nothing.

The render tests to add, in the order the work needs them

#	Entry	Draws	Passes when	Round trip confirms
0	Geometry Baseline	The seven existing shapes	Every getBBox() within 0.3 mm of expected	Shapes land where the viewer says. Already the de facto baseline.
1	Layer Budget	A field in 1, 4 and N colours plus outlines	layerData holds exactly colours + 1, and every shape's colour is in that set	Creative Space lists that many layers, with the powers we intended.
2	Stroke Width Ladder	Lines at 0.05, 0.1, 0.2, 0.5, 1 and 2 mm	Each exported capsule measures its nominal width	The ladder is visibly six different weights, and says which ones the beam actually resolves.
3	Overlap and Occlusion	Stacked opaque shapes, fully and partly covered	Shape count matches the culling policy once one exists	Whether a buried shape burns. The one test that cannot be answered off the machine.
4	Text Fidelity	Baked text at 2, 4, 8 and 16 mm	Glyph paths present, advances correct, anchored left-baseline	The smallest legible size. Extends the existing Text Cal Export into a test.
5	Curve Fidelity	Circles, arcs and a jigsaw connector at several radii	Sampled polyline stays within tolerance of the true curve	Where sampling starts to show as faceting on the engraving.
6	Translucency and Clip	Layered translucent fills; a clipped texture	Flattened colour matches the composite; clipped content accounted for	Whether either concept survives at all — this is the sample the no-speculation rule wants.
7	Style Parity	Each Shape Fill style, canvas against XCS	Raster difference within that style's recorded tolerance	The migration gate. One entry per style, each carrying its own number.
8	Budget and Scale	Progressively denser fields	Shape count and file size stay inside the declared budget	Where Creative Space or the F2 starts to struggle. Extends Test Export (Stress).

Round trips need a record, not a button

The three export buttons today produce a file and nothing else. Each render entry should instead carry a short result log — date, XCS version, what was observed, pass or fail — stored beside the test so the answer survives the person who ran it. That is the gap between manual-test-loop.md as a procedure and as evidence, and it is the same gap exportpatches.md is filling by hand for the export format.

What could go wrong

• Round trips are manual and will lag. The automated half runs in a second; the Creative Space half needs a person. Entries will sit with a green automated result and no round trip, which must be visible as its own state rather than read as a pass.
• Tolerances get tuned until they pass. Same risk as the migration plan. A tolerance is a reviewed number with an image attached, not a knob.
• Raster diffing in a browser is fiddly. Canvas to bitmap is easy; SVG to bitmap at matching scale is less so, and antialiasing differences will show as a noise floor that has to be measured before any threshold means anything.
• Tests 3 and 6 may be unanswerable for a while. Both wait on evidence from the machine, so they should ship as entries in a known-unanswered state rather than be left out and forgotten.

Test and validation of the verifier itself

1. The baseline still passes after the move. The seven geometry checks must report identically before and after being relocated into the Render Tests tab — the move is a refactor and has to be provable as one.
2. Deliberate breakage. Each new entry gets a known-bad variant that must fail it. A render test that has never failed has not been shown to test anything.
3. Noise floor first. Measure the raster difference of a design against itself before setting any threshold, so tolerances are set above the measured floor rather than guessed.
4. Counts on the page. The tab badges read passed, failed, and awaiting round trip, separately.

Answers this needs first

• Do round-trip results live in the page, or in a file beside manual-test-loop.md?
• Should Style Parity be one entry per style, or one entry with a per-style table?
• Is a red round trip a build failure, or a recorded known gap?

How it was found

Rendering Gears both ways and diffing the two rasters gave 67% of pixels differing, which is far too much for the “something looks slightly off” it started as. Registering the two images by their ink showed why: the canvas render is 4:3 and the XCS render is square, and both are full of ink to the very edge. The XCS view is not a worse drawing of the same design — it is a different crop of a larger one.

The canvas is 1200 × 900 px, which at PX_TO_MM is 100 × 75 mm. Measured extents of what actually gets exported:

Style	Exported extent	Size
Gears	x −17.5 … 117.5, y −25.8 … 125.8	135 × 152 mm
World Coins	x −28.1 … 128.1, y −46.2 … 146.2	156 × 192 mm
Jigsaw	x 31.1 … 68.8, y 18.6 … 81.3	38 × 63 mm
Pipes and Gears	x 30.8 … 69.2, y 18.4 … 81.6	38 × 63 mm

Counting shapes against the bed separates the styles that scatter from the styles that fill:

Style	Shapes	On the bed	Straddling	Entirely off
World Coins	260	43%	17%	39%
Christmas Cookies	63	33%	33%	33%
Buttons	64	55%	45%	0%
Gems	161	68%	32%	0%
Autumn Leaves	1,409	87%	12%	1%
Gears	4,434	94%	5%	1%
Rows of Ducks	92	100%	—	—
Jigsaw	651	100%	—	—

A third of World Coins is entirely off the bed. It cannot engrave, and it was never visible in the preview that approved it. Gears loses only 6%, but that 6% is enough to move the ink bounding box from 100 × 75 mm to 135 × 152 mm — and since centerOffsetX/Y centres that box on 50,50, the whole design shifts. That is the visible difference, not the shading.

The decision needed

Three answers, and they are not equivalent. This is the approval this plan is asking for.

	Option	What it means
A	Clip to the canvas	Treat the canvas rectangle as the design surface and clip every shape to it, the way the preview already does. Parity by construction, and nothing can land off the bed. Costs real polygon clipping — flatten each straddling shape and run Sutherland–Hodgman against the rectangle. Changes the output of six styles.
B	Scale to fit	Keep every shape and shrink the whole design until it fits the bed. Nothing is lost, no clipping code is needed. But the engraved size stops matching what the size sliders imply, and a style that scatters far shrinks the part you actually care about.
C	Centre on the canvas, keep the overflow	Compute centerOffset from the canvas rectangle rather than the ink bounding box. One line. It fixes the framing, so the XCS view shows what the preview shows — but shapes outside the canvas still export and still sit off the bed, silently.

Recommendation: A, with C as the same change's first half. The preview is already drawing the honest picture; the exporter is the thing that disagrees with it. B hides a real problem by making everything smaller, and C alone leaves content off the bed where nobody looks.

Two gaps held open by a toggle

Engraved text and clipped texture are the detail the recorder cannot carry, and neither is a decision to take by default. The Shape Fill panel's Detail the Export Drops section turns each one off at the canvas: on, the canvas draws it and the export omits it, so the two renders genuinely differ; off, neither draws it and they agree on its absence. Both default to on, so nothing changes until the question is settled.

Toggle	What it covers	Measured effect
Engraved Text	World Coins denominations and years, Circuit Board resistor codes	World Coins, same page load: 3.62% of canvas pixels change and ΔL moves from −4.28 to −2.83, taking the style inside the antialiasing floor.
Clipped Texture	Buttons marbling, Autumn Leaves gourd ribs and warts	Buttons, same page load: 3.71% of pixels change while ΔL moves 0.08 — the marbling lightens and darkens in equal measure, so mean luminance alone cannot see it.

The change

1. Base centerOffsetX/Y on the canvas rectangle rather than the recorded ink bounds. On its own this makes the XCS view frame the design the way the canvas does.
2. Drop shapes whose bounding box lies entirely outside the canvas — 39% of World Coins, 1% of Gears — before any clipping work, since they need none.
3. Clip the straddlers. Flatten each to a polyline at the existing tolerance and run Sutherland–Hodgman against the rectangle. Closed fills clip cleanly; an open stroke has to be clipped as a polyline and may fall into several pieces.
4. Assert the result: no exported shape may extend beyond the bed, for any style, at any settings.

What could go wrong

• Clipping a stroke is not clipping a fill. A capsule or ribbon is already a filled polygon by the time the recorder sees it, so it clips as a fill — correct, but its round cap becomes a straight cut at the boundary, which is right for a bed edge and wrong-looking if anyone expects a cap.
• Styles that rely on overflow will look cropped, because they are. Coins scatters well past the canvas by design and currently gets away with it. After the change, its edge is the bed edge.
• The centring mandate interacts. GEMINI.md requires the pattern centred on 50,50. Centring the canvas rather than the ink is compatible, but only once the ink is inside the canvas.
• Shape counts drop. Coins loses 39% of its shapes outright. That is a saving, not a regression, but every count recorded before this change stops comparing.

Test and validation

1. Extent assertion. For all fourteen styles, both modes, several densities: every shape's box inside 0–100 mm on both axes. This is the check that would have caught it, and it is four lines.
2. Raster diff, canvas against XCS canvas. The number that started this: currently 67% of pixels differing on Gears. Track it down per style and record what remains once framing is no longer the cause.
3. Shape count before and after, per style, so the clipping is visible as a number rather than discovered later.
4. Round trip on the two worst. World Coins and Christmas Cookies through the manual test loop — they are the styles where the change is most visible, so they are the ones to look at in Studio.

Answers this needs first

• Clip, scale, or keep the overflow?
• If clipping: is the canvas rectangle the design surface, or should the shape outline (the pendant, the cuff) be the clip boundary instead?
• Should a style that loses a third of its shapes to clipping warn, or just clip?

Scope and history

Palette-bounded layers were always the intention. A laser engraves a fixed set of powers, the palette is that set, and a file that asks for more colours than the palette holds is asking for something the machine cannot do. The true-colour path — every shade the draw code invents becoming its own layer — was drift, not a decision, and it went unnoticed for a long time. This plan is the correction, and it applies to all fourteen styles.

Where the extra layers come from

Every distinct colour the recorder sees becomes a layer, and the draw code emits far more colours than the palette holds. Jigsaw is quoted first only because its extras are few enough to count by eye; the arithmetic and the fix are the same for every style:

Piece Colors	Layers today	Breakdown
1	4	1 palette + #15171a board + #3a3f45 board edge + #141414 outline
4	7	4 palette + the same three
9	12	9 palette + the same three

The illustrated styles are far worse, because their shading generates colours that never passed through the palette at all:

Style	Layers	From the palette	Generated
World Coins	51	1	50
Circuit Board	38	2	36
Autumn Leaves	37	4	33
Gears	14	9	5

Choosing a real laser palette instead of True Color does not reduce this. Measured across seven styles, the layer count is identical either way — Coins is 51 both times. mapPaletteToLaser runs once, over the decorative palette, before any drawing happens. Everything invented after that point escapes it entirely, so the leak is downstream of the mapping in every style. That is why the fix has to sit at the point colours become shapes, not at the point the palette is chosen.

Three sources, in order of how much they contribute:

• Shading derivatives. shadeColor() lightens and darkens a palette colour for 3D relief, and each result is a new colour. Translucent highlights add more, since flattenColor() composites them against whatever is behind and emits the composite.
• Fixed decorative colours. Circuit's copper and gold, coin metals, gear silver — hardcoded in the draw functions and never routed through mapPaletteToLaser.
• The board. drawBase() fills and strokes the shape outline in a per-style colour, adding two layers that are backdrop rather than pattern.

The change

Quantise at the single choke point rather than in fourteen styles' worth of draw code. RecordingCtx._emit is the only place a colour becomes a shape, and buildXCSProject is the only place shapes become layers.

1. Tag strokes. _emit already knows isThickStroke. Record it on the shape so outlines are separable from fills.
2. Build the allowed set. After the recording run, read the engine's currentColorPool — the exact subset pickColorSubset chose, already mapped through resolveRenderPalette to real laser entries. That is the N.
3. Snap every fill to the nearest member of that set, and every stroke to the single black outline layer.
4. Decide the board explicitly. Either drop it from the export, since an unengraved area is the material itself, or let it claim one palette entry by choice. It must not create its own layer by accident.
5. Assert before returning. buildXCSProject refuses to hand back a project whose layer count is not N + 1.

Transition

1. Land the tagging and the assertion behind a Layer Mode control offering Palette and Every colour, defaulting to Every colour, so nothing changes on the first deploy and both outputs can be exported from the same design and compared.
2. Walk the fourteen styles, recording the before and after layer count and a canvas capture of each. Jigsaw and the flat styles should be visually unchanged; the 3D and illustrated styles will not be.
3. Flip the default to Palette once the captures have been reviewed. Keep Every colour available for one release so an older .rnr can still reproduce its original export.
4. Remove Every colour, and with it the legacy path.

What could go wrong

• The 3D styles flatten. 3D Glossy and 3D Basic exist entirely to paint highlights and shadows. Snapping those to the palette collapses a glossy pipe to a flat one. Arguably honest — the engraver has N powers, not a gradient — but it is a visible regression and needs to be seen before the default flips.
• Circuit Board's fixed colours. Its Colors slider is disabled and its description says the realistic copper, gold and resistor bands bypass the palette by design. Whether that was a decision or another piece of the same drift is worth settling before it is granted an exemption — a board the F2 can actually engrave needs its colours to be powers like any other style's.
• Nearest-colour in RGB is perceptually wrong. colorDistance2 is a plain squared RGB distance, which misjudges dark and saturated pairs. Two shades a viewer reads as different can snap to one entry while two they read as the same split across two.
• Layer order shifts. Layers carry the processing sequence under pathPlanning: "custom". Merging colours changes which shapes share a layer and therefore the order they burn in.
• Black may not exist in the palette. The outline layer needs a real power. If the laser palette has no near-black entry, the darkest available one stands in and the outline is not as dark as the preview suggests.
• Older exports stop matching. Anything already sent to the machine was built the old way; re-exporting the same .rnr will not produce the same file.

Test and validation

1. The rule itself. For all fourteen styles, both modes, at Colors 1, 4 and maximum: assert Object.keys(canvas.layerData).length === N + 1.
2. No stragglers. Assert every shape's layerColor is either in the allowed set or is the outline black — a set-membership test, not a count, so a merge that loses a colour is caught.
3. Integrity holds. Re-run both joins from xcsformat.md §6 after the merge, since rewriting a shape's layer touches layerData and the device map together.
4. Visual delta. Capture the canvas for every style before and after and put them side by side. The flat styles and Jigsaw must be pixel-identical; the rest are a judgement call to be made from the captures, not from the diff.
5. Shape count unchanged. Quantising colour must not add or drop geometry. Assert the shape count is identical across the two layer modes for the same seed.
6. On the machine. One style through the manual test loop into Creative Space, confirming the layer list reads as N + 1 with sane powers — the only check that proves the F2 accepts it.

Answers this needs first

• Does the board engrave at all, or is it backdrop?
• Was Circuit Board's palette bypass intended, or is it the same drift? If intended, its fixed colours become its palette rather than an exemption.
• Is the black outline layer always black, or the darkest entry in the active laser palette?

The deficit today

Counting what the canvas is asked to draw against what the recorder emits, same seed, Pendant preset, default settings:

Style	Canvas ops	XCS shapes	Lost	Why
Autumn Leaves	1,976	1,409	567 — 29%	all clipped
Buttons	79	64	15 — 19%	clipped; 43 more flattened from translucent
World Coins	260	260	0	but 62 text draws dropped
Circuit Board	693	693	0	but 31 text draws dropped
Gears	4,434	4,434	0	—
Jigsaw	651	651	0	—
Pipes and Gears	967	967	0	—
Painted Lady	1,240	1,240	0	—

Geometry parity is already exact for most styles. The breaks are four, and each has a different cost:

• Clipped drawing is dropped. 567 operations in Autumn Leaves, 15 in Buttons — gourd rib and wart texture, button marbling.
• Text is dropped. 62 draws in Coins, 31 in Circuit Board — denominations, years, resistor codes.
• Translucency is baked. 43 fills in Buttons are composited against their backdrop at record time. The still image matches; the concept does not survive.
• Drop shadows vanish. RecordingCtx declares shadowColor, shadowBlur, shadowOffsetX and shadowOffsetY, and nothing ever reads them. Gears is the only style that uses them — 218 of its 2,674 fills, all from drawSteampunkGear — and losing them is the single largest visual difference in that style. The shadow is what separates one gear from the one behind it; without it the field reads flat and the shapes merge.

What has to be resolved first

Parity cannot be declared until each of these is either implemented or deliberately closed off, and two of them are gated by the no-speculation protocol rather than by effort.

#	Gap	Kind	Note
1	Per-shape stroke width	shipped	RecordingCtx.stroke() converts the recorded lineWidth with PX_TO_MM and builds the capsule at that width; cfg.outlineWeight scales every width together. See the measured result below.
2	Text baking in the recorder	build	The machinery exists for real TEXT objects — charJSONs and fontData per xcsformat.md §11. It is simply not wired to fillText(). Until it is, the panel's Engraved Text toggle decides whether the HTML canvas draws what the export cannot carry.
3	Colour and layer management	blocking	The plan above. Parity in colour is meaningless while one design emits 51 layers.
4	Clip paths	needs a sample	No documented equivalent. Either an .xcs sample proves one exists, or the affected textures are cut from the canvas so both renders agree on their absence. The panel's Clipped Texture toggle makes that second option reversible while the question is open.
5	Alpha	needs a sample	xcs-canvas.js never reads it. Flattening is a reasonable permanent answer — but that is a decision to record, not a gap to leave open.
6	Drop shadows	decision	A laser has N discrete powers and no blur, so a soft shadow cannot be engraved as drawn. Either emit a hard offset silhouette at a darker palette entry — one extra shape per gear, restoring the depth cue — or drop shadows from the canvas as well, so both renders are flat and honest. Doing neither leaves Gears looking like two different patterns.

Measured parity

Both captures come from the same page load, Pendant preset, brushed steel blank, Outline Weight 1×, margin 0. Mean luminance runs 0–255 over every non-transparent pixel; a style is at parity when the two canvases differ by less than the ±3.5 antialiasing floor the renderers set between them. Measured 2026-09-16.

Style	XCS shapes	HTML L	XCS L	ΔL
Flat	251	176.2	176.5	−0.3
3D Basic	429	158.2	158.5	−0.3
3D Glossy	488	167.3	167.3	0.0
Illustrated	973	136.8	137.6	−0.7
Circuit Board	592	174.4	174.6	−0.3
Painted Lady	1,184	149.2	149.9	−0.7
Ducks	1,768	172.6	169.3	+3.3
Gears	4,135	90.9	91.4	−0.5
Christmas	917	121.5	122.6	−1.1
World Coins	6,278	102.3	105.8	−3.5
Gems	2,185	153.8	154.8	−1.0
Buttons	1,929	182.2	183.6	−1.4
Autumn Leaves	1,379	129.7	129.3	+0.4
Jigsaw	652	86.2	87.1	−0.9

Two defects closed together here, and only one of them was the stroke width. Forcing every stroke to a single physical width was 11× too wide for Flat's gear rings, a few tenths of a millimetre apart on a 6.7 mm gear, and 11× too narrow for the 27 px black underlay drawPipeOutline draws to make Illustrated's outlines. The second defect was in this canvas rather than the exporter: viewer.js's restyleInPlace repeated the fill and stroke logic instead of calling it, and set stroke on filled shapes without a stroke-width. SVG then defaults to one user unit, and a user unit on this bed is a millimetre, so every restyled shape wore a 1 mm black band and Flat's gears painted as solid black discs. Both canvases now call applyPaint() in xcs-canvas.js, so the logic has one home.

The change

1. Make the deficit visible. Land the op-count harness first, as a test that reports canvas operations against XCS shapes per style. It is the instrument for everything below and it already exists in rough form.
2. Carry stroke width through. Done. _emit takes the recorded lineWidth, converts with PX_TO_MM, and builds the capsule at that width. The panel's Outline Weight slider scales the artwork's own weights rather than replacing them: 1× engraves each line as drawn, 0× means no outlines. save() and restore() now carry the paint state, since a lineWidth set inside a save block has to stop applying at the matching restore.
3. Bake text. Route fillText() through the existing glyph path, emitting one PATH per character at the recorded transform.
4. Close clip and alpha by decision. Once 1 to 3 land, the residual is only these two. Either a sample arrives and they are implemented, or the canvas stops drawing what cannot be exported — parity by subtraction is still parity, and is honest about what the machine can do.
5. Assert it. The harness becomes a gate: a style whose counts diverge fails.

Transition

1. Harness first, reporting only. Record a baseline for all fourteen styles so every later step is measured against it rather than against memory.
2. Stroke width, then text. Both add shapes to the export, so file sizes rise — Autumn Leaves most of all. Re-measure against the 2,000-shape guard at the same time.
3. Colour and layer plan lands.
4. Clip and alpha resolved by sample or by subtraction.
5. Harness flips from reporting to failing.

What could go wrong

• Parity makes the files bigger, not smaller. Every gap closed adds geometry. Autumn Leaves gains 567 shapes before anything else changes, and Gears is already 2.2× over the shape guard.
• Real line widths may not be printable. A canvas lineWidth of 1 px is 0.083 mm, below what the beam resolves. Widths need a floor, and the floor changes the drawing.
• Text at these sizes may be unreadable. A coin denomination is a few millimetres wide. Baking it faithfully may produce something that engraves as a smudge — in which case dropping it, and dropping it from the canvas too, is the better answer.
• Parity by subtraction is a product decision. Removing gourd texture and button marbling from the canvas makes the two renders agree by making the preview worse. That is a call to make deliberately, not one to arrive at because a sample never turned up.
• Counting operations is not comparing pictures. Equal counts do not prove equal output; the raster comparison below is what actually settles it.

Test and validation

1. Operation count. Per style, per mode: canvas fill plus stroke calls against XCS shape count, with the dropped ones attributed to clip, text or empty path. Cheap enough to run on every change.
2. Raster diff. The real test. Render the canvas to a bitmap, render the XCS project's SVG to a bitmap at the same size, and compare pixel by pixel. Report a percentage per style and keep the difference image. This catches what counting cannot — a shape that exports but lands in the wrong place or the wrong colour.
3. Per-style budget. Each style declares its acceptable difference. Jigsaw and the flat styles at zero; the illustrated styles at whatever the captures justify, written down rather than assumed.
4. Regression on shape count. Track shapes and file size per style against the baseline, so the cost of each closed gap is visible as it lands.
5. On the machine. The style with the largest remaining difference through the manual test loop. A raster diff proves our two renders agree with each other, not that either agrees with the F2.

Answers this needs first

• Is parity the goal for every style, or do the illustrated styles get a declared budget?
• If no clip sample arrives, do the affected textures come out of the canvas?
• Does Outline Width become a multiplier on the artwork's own widths, or stay an override? Gears asks for 1.5 px, which is 0.125 mm, and gets 0.2 mm — every line 1.6× heavier than drawn. Coins asks for 181 distinct widths, Buttons 157, Gems 104, and all of them get the one.
• Hard offset shadow, or no shadow anywhere?

How the rule was lost

Every tab in the tool renders through XCSViewer and nothing else. Fifteen of the sixteen still do. Shape Fill is the single exception: it carries a renderTarget of html or xtool, and it defaults to html — so the first thing anyone sees is the mode that is not real.

The file's own header says where that came from: ported unchanged from laser-experiments/laser-fill-generator. The canvas arrived as baggage with a port of a standalone canvas app, which still exists alongside the tool. The rule was not argued away, it was carried around, and then fourteen styles were built and tuned against the canvas rather than against the file.

The cost is the chasm the rule existed to prevent. The two plans above are the measurements of it: a style can look finished on the canvas while dropping 29% of its drawing, collapsing 579 line weights into one, and asking for 51 laser layers.

How far each style is from surviving without the canvas

Counting what the canvas asks for that the XCS project cannot yet carry — clipped drawing, text, translucency, distinct line widths, and layers generated outside the palette:

Style	Clipped	Text	Translucent	Line widths	Generated layers	Total
Jigsaw	0	0	0	2	3	4
Gears	0	0	0	2	5	6
Flat	0	0	0	2	7	8
Rows of Ducks	0	0	0	1	11	11
3D Basic	0	0	0	3	12	14
Christmas Cookies	0	0	0	8	7	14
Painted Lady	0	0	0	2	15	16
Pipes and Gears	0	0	0	8	11	18
3D Glossy	0	0	0	4	16	19
Circuit Board	0	31	0	7	36	73
Gems	0	0	0	22	59	80
Buttons	15	0	43	21	26	104
World Coins	0	62	0	22	50	133
Autumn Leaves	567	0	0	579	33	1,178

Nine styles are within reach on the strength of the colour plan alone. Five are not, and Autumn Leaves is an order of magnitude past the rest.

The change, in two halves

Half one: raise the XCS project to the level the styles need.

1. Colour and layer management, so a style's colours are powers.
2. Per-shape stroke width, so line weight survives.
3. Text baking through the recorder.
4. Clip and alpha resolved — by a sample from Creative Space, or by a recorded decision that they are out of scope.

Half two: bring each style onto it, one at a time.

1. Take the style in the order above, cheapest first.
2. Render it both ways and diff the rasters.
3. Close the difference — by teaching the exporter, or by changing the drawing so it only asks for what the file can carry.
4. Agree its tolerance and write it down. Not every style needs zero; a style needs a number it meets.
5. Mark it migrated. Once a style is migrated it is developed against XCS output only.

Then remove the split.

1. Flip renderTarget to default to xtool — a one-line change that can land early and immediately stops new work being done against the canvas.
2. When every style is migrated, delete the toggle, the second viewer, and updateShapeFillViewerVisibility.
3. The canvas stays, but only as the recorder's input. It stops being something anyone looks at.

What could go wrong

• A style may not survive the move. Autumn Leaves at 1,178 may cost more than it is worth. Retiring a style is an allowed outcome — a style that only exists on a canvas is exactly what the rule was written to prevent.
• The canvas is faster. The XCS canvas draws SVG shapes and Gears emits 4,434 of them. Interactive slider dragging may become unusable before the shape-count guard is in. That guard stops being a nicety.
• Editing the shape needs a canvas. Edit Shape drags handles on the canvas element. That interaction has to survive the removal of the canvas as a view, or move onto the XCS canvas.
• Flipping the default surfaces everything at once. Fourteen styles will look wrong on first open. Worth doing early anyway, because that is the honest picture.
• Tolerances can be set to hide the problem. A generous number makes a style pass without fixing it. Tolerances belong in review, with the difference image attached.

Test and validation

1. The rule as a test. No component outside xcs-tab.js may hold a second render path. Assert that renderTarget, or anything like it, appears in no component — a grep-level check that keeps the rule from being lost a second time.
2. Raster diff per style, canvas against XCS project, with the difference image kept and the per-style tolerance recorded beside it.
3. The distance table as a burn-down. Re-run the counts above after each step of half one. Every number should fall; any that rises is a regression with a name.
4. Shape count and file size per style, tracked in the same run, since closing gaps adds geometry.
5. On the machine. The migration is not finished on a raster diff. Each migrated style goes through the manual test loop at least once — that is the whole point of the rule.

Answers this needs first

• Flip the default to xtool now, before the work, or at the end of it?
• Is retiring a style an acceptable outcome, or must all fourteen migrate?
• Where does Edit Shape live once the canvas is not a view?