Add a Blueprint Info editor: name, icons, description, and grid alignment

[koenigstag]

Summary

• New "Blueprint Info" dialog for the blueprint itself (not an entity), opened via a button in the top-left corner next to the FBE logo — the editor had no way to view or change a blueprint's own name/description/icons/grid-alignment before this, only round-tripping them silently on import/export.
• Name and Description — plain/multiline text fields, routed through history.updateValue so edits are undoable like everything else.
• Icons — up to 4 slots, left-click opens the icon picker (items/fluids/recipes/virtual signals), right-click clears a slot.
• Grid alignment — a new section covering snap-to-grid, absolute-snapping and position-relative-to-grid, the three blueprint-string fields the editor already decoded/re-encoded but never exposed:
  • "Snap to grid" checkbox, Grid size (Width/Height), Grid position (X/Y), and an Absolute/Relative choice.
  • The exact serialization rules (when each field is written vs. omitted, and what "enabling from off" defaults to) were verified by decoding several real exported blueprint strings by hand rather than guessed — see commit messages for the specifics. This caught and fixed a real bug where turning snapping back off could leave a stale absolute-snapping: true behind in the exported string.
  • New RadioButton control (circular) for the Absolute/Relative choice, since Checkbox draws a rounded square that reads as an independent toggle rather than one of two options.

Test plan

• vp check / vp test pass
• Manually verified end-to-end: dialog opens from the corner button; name/description/icons edit and persist; grid-size/position fields enable/disable correctly across Snap-to-grid/Absolute/Relative combinations; round-tripped several real blueprint strings (Absolute, Relative, grid off) through the app and confirmed the re-exported JSON matches the original byte-for-byte in the relevant keys; undo/redo works throughout.

[wormeyman]

I've updated the branch onto current base, which pulls in a CI job that didn't exist when you opened this: the Playwright suite runs on PRs now. It's running above. Locally it comes back 191 of 192, and I think the one failure is real.

blueprint-round-trip.spec.ts:

-   "serializedHash": 825830683,
+   "serializedHash": 120098912,

Everything else in that fixture holds. All the counts, both position checksums. That narrows it to a field vanishing from the serialized JSON with no geometry moving.

The field is position-relative-to-grid. In Blueprint.serialize:

'position-relative-to-grid':
    snapToGrid && !absoluteSnapping && !positionIsDefault
        ? positionRelativeToGrid
        : undefined,

It only writes when snapping is Relative. I decoded the corpus to see how often that branch is taken: of 367 blueprints, 325 carry snapping, and every one of them is absolute-snapping: true. The single blueprint that also carries a grid position, "Biolabs 750 SPM" in test-blueprints/EARN/pocket-base-space-age-v22.1.2.txt at {80, 106}, is absolute as well. So on real data the condition never fires and the value is dropped on export.

Running the same probe against base and against this branch, the count of blueprints that keep a grid position through a round trip goes from 1 to 0.

My guess is that position-relative-to-grid belongs to Absolute rather than Relative. The other half of the PR points the same way: the X/Y boxes on the Absolute row have nothing behind them, as your own comment there says, so anything typed into them is discarded, while the live X/Y sits under Relative. Swapping the two would fix both halves at once. Worth checking against the game before changing anything, though. I could be wrong about which way round it goes, and tools/oracle/ is set up for exactly this kind of question.

One unrelated thing while you're in there: BlueprintInfoButton is added outside the if (!isMobile.any) block in UIContainer, so the edit button appears on mobile, where the editor is meant to be view-only.

The alignment work itself is a real gap filled, and the serialization rules you worked out by decoding real strings are the right way to have got them.

[wormeyman]

I said above that my guess was that position-relative-to-grid belongs to Absolute rather than Relative, and that it was worth checking against the game before changing anything. I've now done that, on 2.0.77: #226.

The guess was right, and here is the table rather than the reasoning:

case	set snap	set abs	set pos	wrote snap	wrote abs	wrote pos
relative-origin	2,2	false	0,0	2,2	-	-
relative-offset	2,2	false	3,5	2,2	-	-
absolute-origin	2,2	true	0,0	2,2	true	-
absolute-offset	2,2	true	3,5	2,2	true	3,5

Set a grid position in relative mode and the game writes no position key at all. Set the same one in absolute mode and it writes it. So the condition wants to be snapToGrid && absoluteSnapping && !positionIsDefault, and the {0, 0} rows say the non-default check is right to be there: the game omits the key at the origin in both modes.

I put both candidate rules into the probe and scored them against every measured row before writing any of this down. The inversion agrees on all seven rows that have a grid; the current condition disagrees on three.

Two things from the probe worth having if you go near this.

Setting blueprint_position_relative_to_grid turns blueprint_absolute_snapping on. My first run set snap, then absolute, then position, so the position write flipped absolute back on afterwards and every row exported as absolute. Relative mode was never reached and the relative rows measured nothing while looking entirely reasonable. If you probe this yourself, set position before absolute.

And a grid position with no snap-to-grid is a state the GUI cannot reach, which the game handles inconsistently: it writes keys with no grid beside them and does not reconstruct them on import. I recorded those rows but did not score them. Worth knowing because your refreshEnabled already disables the position fields when the grid is off, which is the right call for a reason the game agrees with.

The rest of the review stands: the Absolute row's X/Y still needs backing by the real field rather than the placeholder, and BlueprintInfoButton is still outside the isMobile gate.

[wormeyman]

Reopened. I closed this yesterday while merging #226, and there was no decision behind it. Sorry for the noise.

Nothing has changed from the two comments above. The serialize condition still wants inverting to snapToGrid && absoluteSnapping && !positionIsDefault, and BlueprintInfoButton still wants moving inside the if (!isMobile.any) block in UIContainer.

What has changed is that #226 is merged, so tools/oracle/fixtures/blueprint-snapping.json and tests/blueprint-snapping.spec.ts are on the base branch now. Merge base in and two of that spec's five tests fail against the current condition and pass against the inverted one, so you can check the change locally without going near the game.

The alignment section is a real gap and I want it in.

[wormeyman]

For whatever agent picks this up, here is the same thing in a form you can act on directly. Merge wormeyman-space-age-support in first: the fixture and spec named below landed after this PR was opened.

1. Invert the serialize condition

packages/editor/src/core/Blueprint.ts, in serialize():

// current
'position-relative-to-grid':
    snapToGrid && !absoluteSnapping && !positionIsDefault
        ? positionRelativeToGrid
        : undefined,

// wanted
'position-relative-to-grid':
    snapToGrid && absoluteSnapping && !positionIsDefault
        ? positionRelativeToGrid
        : undefined,

This was measured against Factorio 2.0.77, not reasoned about. The game writes position-relative-to-grid under absolute snapping and omits it under relative. The table is tools/oracle/fixtures/blueprint-snapping.json and the probe that produced it is tools/oracle/probe-blueprint-snapping.mjs. Do not edit either one to make something pass. If the fixture and the code disagree, the code is wrong.

The !positionIsDefault half stays as it is. The game omits the key at {0, 0} in both modes.

2. The UI half follows from the same rule

packages/editor/src/UI/BlueprintAlignment.ts. refreshEnabled currently enables the live X/Y whenever the grid is on, with a comment saying only serialization cares which mode is chosen. Under the measured rule that is now a way to lose a value: a position typed while Relative is selected never reaches the export. The two boxes on the Absolute row, m_AbsoluteXInput and m_AbsoluteYInput, have no Blueprint field behind them, and Absolute is the mode that carries the real position, so those and the live pair want reconciling into one set of inputs.

How that is presented is open. What is not open is that a number the user can type has to reach the exported string or be visibly unavailable.

3. Mobile guard

packages/editor/src/UI/UIContainer.ts. blueprintInfoButton is passed to the unconditional addChild call at the top of the constructor, so the button appears on mobile, where the editor is view-only. Move it into the if (!isMobile.any) block just below, which already guards quickbarPanel and wiresPanel.

Verify before pushing

vp check
vp test
npm run localpreview   # repo root, separate terminal, leave it running
npx playwright test tests/blueprint-snapping.spec.ts tests/blueprint-round-trip.spec.ts

Both dev servers have to be up for the Playwright half, which is what localpreview starts. blueprint-snapping.spec.ts has five tests and two of them fail against the current condition. blueprint-round-trip.spec.ts checks a committed fixture and should pass untouched. If it does not, do not refresh that fixture. A moved hash there means real blueprint output changed and the change is the thing to look at.

[koenigstag]

Fixed the places you've mentioned.

Inverted the serialize condition to Absolute (measured against 2.0.77, issue #226), reconciled the grid-position X/Y inputs into the one field it actually backs, moved BlueprintInfoButton inside the mobile guard, and fixed positionIsDefault stripping an explicit {0, 0} that blueprint-snapping.spec.ts expects to pass through — all three review items plus what the test caught, vp check/vp test and both named specs green.

[wormeyman]

Re-reviewed against the base branch as it stands now. All four items are fixed, and I checked each one against the code rather than taking the summary.

The one worth calling out is the positionIsDefault to positionIsUnset change, because you went against what I wrote and you were right to. My comment said the !positionIsDefault half stays as it is. But tests/blueprint-snapping.spec.ts landed after I wrote that, and its fifth test pins that an explicit {0, 0} passes straight through. Base behaviour was verbatim pass-through, so keeping !positionIsDefault would have failed a test I had just merged. The comment you left at that site says so clearly. Good catch.

Two things left.

absolute-snapping stopped being pass-through and nothing pins it

'absolute-snapping': snapToGrid && absoluteSnapping ? true : undefined,

Base forwarded that field as it arrived. Now a blueprint carrying absolute-snapping: true with no snap-to-grid loses the key on export.

I think the behaviour is right. tools/oracle/fixtures/blueprint-snapping.json has that exact state in its no-grid-absolute-set row, and its roundTrip.absolute comes back false, so the game does not reconstruct it on import either. Your reasoning in the comment above it is sound too: with the UI able to turn snapping off, the boxed store keeps a stale true that has to be gated somewhere.

What bothers me is that it sits two lines from a comment arguing the opposite principle for the position field, that this layer round-trips what it was given, and nothing tests it. No corpus blueprint is in that state, which is why the round-trip hash did not move. A sixth test in blueprint-snapping.spec.ts would close it, and the fixture already has the row to write it from.

acceptedSignalIcons() already exists

Entity.acceptedDisplayPanelIcons at Entity.ts:1721-1726 is the same three lines. factorioData.ts is the better home, since the function reads nothing but FD and has no entity in it. The miss is that the original site was left alone, so the list is now written down twice. Point acceptedDisplayPanelIcons at the new function.

What I checked and found clean

The setters now route through History, so I looked at the load path. this.name = data.label runs in the constructor and this.description = data.description runs just above this.history.reset(), so neither leaves a stray undo entry for a user's first Ctrl+Z after a load. The three snapping fields write their stores directly and skip history entirely, which is right.

RadioButton copies Checkbox's redraw pattern, including replacing both graphics without destroying the old ones. That matches what is already there, so I am not asking you to change it.

Tests

There are none, and this PR adds six Blueprint setters, a new control, two new dialogs and a TextInput mode. The part I would most want covered is undo. snapToGrid = undefined for turning snapping off goes through History.updateValue with undefined as a real value meaning "delete this key", and nothing exercises that path.

The alignment section is the gap I wanted filled and I still want this in.

[wormeyman]

Re-reviewed at 2497d246. The four items from last time are all fixed, and I checked each against the code rather than the summary. acceptedSignalIcons() is shared now and acceptedDisplayPanelIcons points at it. The sixth blueprint-snapping.spec.ts test is in, and it pins the absolute-snapping gating I asked about.

I drove this one in a browser instead of only reading it, because the new "Grid position as a real entity shift" work is the kind of change a green suite cannot speak for. Both dev servers up, throwaway probe, numbers printed. The first five items below are all measured that way rather than reasoned about, and the first two are why I am not merging yet.

1. "Grid position" does not change the exported blueprint at all

Two chests, one nudge of (-3, -4):

model before : #1(-3.5,-3.5)  #2(4.5,4.5)
model after  : #1(-6.5,-7.5)  #2(1.5,0.5)

export before: #1(-4.5,-4.5)  #2(3.5,3.5)
export after : #1(-4.5,-4.5)  #2(3.5,3.5)

The model moves. The exported coordinates do not move at all.

serialize() re-centres every position through getCenter(), which is Math.round((minX + maxX) / 2). Shift every entity by a whole number k and minX, maxX and the centre all shift by k as well, since Math.round(v + k) === Math.round(v) + k for whole k. Then e.position.x -= center.x takes the same k straight back out. The firstRailPos parity bump survives it too, because both halves of firstRailPos.x - center.x move together. And k really is always whole here: parseGridValue is parseInt, and the restriction is /^-?\d*$/. So the cancelling is exact, not approximate.

tests/blueprint-grid-position.spec.ts cannot see this. Test 1 reads model positions, test 2 reads the three snapping keys, test 3 reads undo. None of them reads an exported entity coordinate.

2. On a blueprint with tiles, the nudge slides entities off the floor

translateEntities walks this.entities and never this.tiles. getCenter() averages both. So the two disagree, and this is the one case where the nudge does reach the export.

Two chests plus two concrete tiles, nudge of x = 3:

export before: entities #1(-4.5,-4.5) #2(3.5,3.5)   tiles (-5,-5) (3,3)
export after : entities #1(-5.5,-4.5) #2(2.5,3.5)   tiles (-3,-5) (5,3)

Entities moved one tile left. Tiles moved two tiles right. Re-import that and the machines stand three tiles away from the concrete they were built on.

So the feature does nothing on a blueprint with no tiles, and damages one that has them. I think that points at something structural: a grid nudge cannot be an entity translation while serialize() owns the centring, because the centring will always take the translation back out. Worth settling before more code goes on top.

3. Opening Blueprint Info crashes on five of the twelve corpus files

BlueprintIconSlot.updateContent calls F.CreateIcon(name) with nothing catching it. CreateIcon throws for any name that is not an item, fluid, recipe, signal or inventory group. Planet names are none of those.

Measured against packages/exporter/data/output/data.json and the committed corpus: 17 blueprint-level icon references use vulcanus, fulgora, gleba or nauvis, spread over five files. JEPAKAZOL/vulcanus-starter-mk2.txt is a book whose five blueprints each carry one.

Loading that file and clicking the corner button:

Error: No item, fluid, recipe, signal or inventory group named vulcanus
    at CreateIcon (functions.ts:147)
    at BlueprintIconSlot.updateContent (BlueprintInfoEditor.ts:35)
    at new BlueprintIconSlot (BlueprintInfoEditor.ts:22)
    at new BlueprintInfoEditor (BlueprintInfoEditor.ts:79)

The dialog never opens, and it throws again on every later click.

There is a second effect worth knowing about, because it outlives the click. Dialog's constructor runs Dialog.s_openDialogs.push(this) at line 37, before the subclass body throws, so each failed open leaves an entry behind that nothing removes. openDialogCount reads dialogsContainer.children.length, so the test hook cannot see it, but Dialog.anyOpen() can. Measured with a control:

	press E	openDialogCount
clean load	inventory opens	1
after one failed open	nothing happens	0
same page, press E again	inventory opens	1

So the keypress after the crash is swallowed. The control opens the inventory on the first press, which is what makes the treatment mean something.

BookDialog in #227 already wrote the guard this wants, as tryCreateIcon. Worth lifting it somewhere both can reach rather than writing it twice.

4. A negative Absolute X or Y cannot be typed, and the wrong sign is exported

Snapping on, no position-relative-to-grid on the blueprint. Typing character by character into the Absolute X box:

type "-"  ->  box reads "0"
type "5"  ->  box reads "5"     (wanted "-5")
type "-"  ->  box reads "0"
type "7"  ->  box reads "7"     (wanted "-7")

exported position-relative-to-grid: {"x":7,"y":0}

It is not a first-try problem that clears up on a retry. It never works, and the exported value carries the opposite sign to the one the user asked for.

The loop is: m_XInput.on('changed') fires on each keystroke, commitPosition() reads parseGridValue('-') as 0, the setter sees a real change and emits, the listener at line 228 calls refreshFromBlueprint(), and that writes .text = '0' back into the box being typed in.

The comment at BlueprintAlignment.ts:197-204 explains why the other fields are safe on changed: "their commits re-write the blueprint with the current full text rather than clearing anything, so an intermediate keystroke is harmless to repeat." That reasoning is the part that does not hold. The commit does not clear the field, but the emit it causes comes back round and overwrites it.

5. Clearing the Grid Width box exports a grid the game will not take

select all in Width, press Backspace  ->  box reads "0"
exported snap-to-grid: {"x":0,"y":4}

parseGridValue('') is 0 and serialize() forwards snap-to-grid as it stands. Same loop as item 4, and the same reason the box cannot be left empty for even one keystroke. There is no upper bound either, so 9999 goes straight through.

Smaller things

Control+A in the new spec. blueprint-grid-position.spec.ts:97 uses page.keyboard.press('Control+A'). #207 already fixed exactly this in display-panel-editor.spec.ts:165, with a comment on the line above: on macOS Control+A is the emacs "beginning of line" binding, not select all. Nothing gets selected, the typed value lands next to whatever was there, and the assertion fails. It is green on the Linux CI shards and red on my machine, which is the same asymmetry #207 records.

Every field is on changed, so every keystroke is an undo step. Name, Description, Width, Height and both Absolute boxes. Typing a 20-character name puts 20 entries on the history stack, and one Ctrl+Z takes back one character. You found this shape for Grid position in the last commit and moved it to blur. The other five want the same treatment.

commitGridPositionNudge on blur has its own trap. Opening the icon picker builds a Dialog, whose constructor calls updateDOMInputVisibility(), which sets display: none on Blueprint Info's fields. The browser blurs a focused field when it is hidden, so the pending nudge commits. I did not measure this one, so treat it as a thing to check rather than a finding.

The class doc has the ordering backwards. BlueprintInfoEditor.ts:72-73 says Editor.loadBlueprint calls Dialog.closeAll() before swapping G.bp. Editor.ts does G.bp = bp at 328 and Dialog.closeAll() at 332, with new BlueprintContainer and initBP() in between. It is harmless today because nothing in that gap touches the outgoing blueprint, but that is a weaker promise than the one written down, and the comment is what the next person will read.

RadioButton duplicates Checkbox. Same field triple, same constructor shape, same fill expression, same cacheAsTexture tail, same remove-and-redraw setter. Its checked setter also drops the old graphics without destroying them, and refreshFromBlueprint() runs on every keystroke, so the orphans accumulate. There is no e.button === 0 guard either, so a right click selects the option, which is the opposite of what right click means everywhere else in this dialog.

text-input.spec.ts:279 hardcodes page.mouse.click(170, 24) for the corner button, while openBlueprintInfoEditor exists in the very same PR so that the coordinate lives in one place, and blueprint-grid-position.spec.ts uses it.

Where this leaves it

The name, icons and description half is good work and I want it. The snapping half is right too, and the fix you made against my advice on positionIsDefault is still the best catch in this PR.

Items 1 and 2 are the blockers. Item 3 is a crash on real files people will load. Items 4 and 5 are a single mechanism, the commit-and-refresh loop, and closing that closes both.

One thing I would raise before the code changes: item 1 suggests the game's own "Grid position" may not be an entity translation at all. What the probe in #226 measured is which snapping mode carries position-relative-to-grid, not what the second X/Y pair does. tools/oracle/ can answer that directly, and the answer decides whether item 1 wants a fix or a different feature.

[wormeyman]

I said in my last comment that the premise under "Grid position" was worth asking the game about before changing any code. I have now done that, on 2.0.77, the same binary #226 was measured on.

The premise is refuted. Setting a grid position does not move entities.

Here is the table rather than the reasoning. Two chests at (0.5, 0.5) and (8.5, 8.5), snapping on, absolute:

grid position set	model after	exported	round-tripped	position-relative-to-grid written
none	#1(0.5,0.5) #2(8.5,8.5)	same	same	absent
{0, 0}	#1(0.5,0.5) #2(8.5,8.5)	same	same	absent
{3, 5}	#1(0.5,0.5) #2(8.5,8.5)	same	same	{3, 5}
{10, -7}	#1(0.5,0.5) #2(8.5,8.5)	same	same	{10, -7}

Nothing moves. Not in get_blueprint_entities(), not in the exported string, not after importing that string back into a second stack. The game writes the key and leaves every coordinate exactly where it was.

So there is no second thing to model. position-relative-to-grid is the whole feature, #226 already measured everything there is to know about it, and the Absolute X/Y pair you already wired up is the correct and complete implementation. translateEntities and Entity.forceMoveBy are solving a problem the game does not have.

The probe is tools/oracle/probe-blueprint-grid-position.mjs and the table is tools/oracle/fixtures/blueprint-grid-position.json. Do not edit either to make something pass. Two captures in a row are byte-identical, so if a third disagrees, that is a finding.

The control is the part worth reading

A result like this is mostly zeros, and zeros are exactly what a broken probe produces. So there is a positive control: a shifted-entities case that places the same two chests three tiles left and four up through set_blueprint_entities, touching no snapping property at all. Its exported coordinates have to differ from the baseline, and they do:

baseline         #1(0.5,0.5)   #2(8.5,8.5)
shifted-entities #1(-2.5,-3.5) #2(5.5,4.5)

Without that, "the coordinates never changed" would read the same whether the finding is real or the probe is comparing a value with itself. That is the #133 item 4 lesson in its null-result form, and it is the only reason the zeros above are evidence.

One new thing about the API, which confirms #226 from the other end

#226 found that setting blueprint_position_relative_to_grid turns blueprint_absolute_snapping on, and warned to set position before absolute.

This probe found the reverse: setting blueprint_absolute_snapping = false clears the position. The readback control caught it, on the one relative-mode row in the sweep, which came back holding no position at all.

That is worth knowing for two reasons. It means a relative row cannot be scored here, because it holds no grid position by the time anything is read, so asking whether its grid position moved the entities is a question about a value that is not there. Those rows are recorded and left unscored rather than counted as "did not move". And it is independent confirmation of #226's result from the opposite direction: relative snapping does not carry a position because the game takes the position away, not merely because the exporter drops it.

What this means for the PR

Items 1 and 2 in my last comment are not bugs to fix. They are a feature to remove.

Deleting the "Grid position" row, Blueprint.translateEntities, Entity.forceMoveBy and tests/blueprint-grid-position.spec.ts takes both blockers with them, and it takes the tiles problem with them too, since nothing translates entities any more. What is left is the name, icons, description and the alignment section built on Absolute's own X/Y, which is the part I wanted and which is already right.

That leaves the crash on planet icons, and the commit-and-refresh loop behind the negative-value and zero-width bugs. Those are real and still want fixing. They are also much smaller than what just went away.

Sorry for the round trip on this one. The screenshot reading was a reasonable inference and I did not question it either until the export numbers came back identical.

[wormeyman]

One line in this PR is now an enforced check rather than a review note, so here is the heads-up before you hit it.

#233 merged as 7d2f3d33. It adds tests/spec-modifier-keys.test.ts, a text scan over the specs that runs under vp test inside checks, in milliseconds. When you next merge base into this branch, blueprint-grid-position.spec.ts:97 fails it. I ran the merged guard against your whole tests/ directory to be sure of the scope, and that line is the only match across all three spec files this PR touches:

1 spec chord(s) hardcode a platform modifier:

  blueprint-grid-position.spec.ts:97  Control+A
      await page.keyboard.press('Control+A')

The fix is the same one #207 made at display-panel-editor.spec.ts:165:

await page.keyboard.press('ControlOrMeta+A')

Why this needed a guard and not another comment

I flagged this line in my review a few hours ago, and I want to be clear that the guard is not aimed at you. It exists because the same thing happened to me. #207 fixed exactly this bug, wrote a five line comment above the corrected call explaining the trap, and the comment still did not reach the next person writing a spec in a different file. That is the failure the guard is for.

The mechanics, since your CI is green today and will stay green on this: on macOS Control+A is the emacs "beginning of line" binding, not select all. Nothing gets selected, the typed value lands next to whatever was in the field, and the assertion sees both. It passes on Linux. Every runner this repo has is ubuntu-latest, including checks and all four Playwright shards, so the browser suite cannot catch it no matter how much of it runs. That is why the new test reads spec source instead of driving a browser.

The rule it encodes

Not "never write Control". There are two cases and they want opposite things:

• A chord that reaches the app through actions.ts stays Control. ModifierKey there is 'Control' | 'Shift' | 'Alt', so the app has no Meta binding at all.
• A chord that reaches a focused DOM <input> wants ControlOrMeta, because the OS binding differs by platform. Only TextInput puts a real input on the page, so this case is small: select all, copy, cut, paste and undo inside a text field. Yours is the first kind of case in the second category since Add a settings editor for display-panel entities #197.

A regex cannot separate those, so the test flags both and an ALLOWLIST entry carries the distinction in writing. One entry on base today, chest-filters.spec.ts's undo. If you ever need a literal Control for a chord that reaches the app, add an entry with a reason rather than working around the check.

[wormeyman]

My last two comments point at the same file in opposite directions, so here is which one wins.

The deletion is the one to act on. If tests/blueprint-grid-position.spec.ts goes, line 97 goes with it, the guard has nothing to flag, and there is no ControlOrMeta edit to make. That note only applies if some form of that spec survives, or if the chord turns up in another spec later.

Sorry for the crossed wires. I posted the guard heads-up without re-reading what I had written above it.

[koenigstag]

Closed PR by mistake. Reopening

[wormeyman]

I have detached this repo and it is standalone now you may have to re-fork this repo and resubmit the PR's. @koenigstag

[wormeyman]

trying to reopen