DEV Community: Zhuo Jinggang

Generative Harness: When Agents Start Writing Their Own Execution Structures

Zhuo Jinggang — Sat, 30 May 2026 10:11:48 +0000

Agent systems have mostly been built around a simple assumption: the model may decide what to do next, but the surrounding execution structure is designed by the developer. We give the model tools, define a loop, manage context, constrain permissions, record traces, add retries, and sometimes insert human approval. The model acts, but the system decides the shape of action.

That assumption is starting to weaken.

A new pattern is emerging across several parts of the agent stack. Models are no longer only choosing the next tool inside a fixed loop. They are beginning to generate parts of the execution structure itself: code that composes tools, scripts that coordinate workers, workflows that decide how a task should be decomposed, parallelized, checked, and summarized. I would call this pattern generative harness.

The term is less important than the shift it points to. A harness is the execution structure that turns model capability into task completion. In earlier systems, this structure was fixed or developer-authored. In generative harness, the model begins to produce task-specific orchestration, and the runtime executes it.

This is powerful, but it changes the central problem. The bottleneck is no longer just whether an agent can execute. It is whether we can verify the orchestration it generated.

From actions to orchestration

The earliest tool-calling agents were deliberately simple. The model selected an action, the tool returned an observation, and the next model call decided what to do with it. This loop is limited and often inefficient, but it has one useful property: feedback is local. If a tool call uses the wrong argument, tries to read a missing file, or hits a permission error, the mistake usually appears immediately. The next turn can correct it.

LangGraph represents a more explicit answer to the same problem. Instead of relying on an implicit loop, the developer can define the orchestration as a graph: state, transitions, checkpoints, human-in-the-loop gates, and durable execution. LangGraph is still an important milestone because it makes agent orchestration visible and controllable rather than hiding it inside a generic loop. But the orchestration is still primarily developer-authored. The graph exists before the task runs, and the model acts within it. LangGraph’s own positioning as a low-level orchestration framework for long-running, stateful agents makes this role clear.

This is a useful contrast for what is changing now. Developer-authored orchestration is valuable because it is inspectable and governable. It is also expensive to design for every task shape. Some tasks require fan-out search, some require map-reduce, some require independent verification, and some require a multi-stage migration followed by tests and repair. A single fixed loop is too weak, while a pre-authored graph can be too static. The natural question is whether the model can generate the right orchestration for the task at hand.

CodeAct is one answer to that question at the action level. Its core idea is to let the model use executable code as the action, rather than being limited to JSON calls or predefined text commands. In the CodeAct paper, executable Python code becomes a unified action space that can compose tools and dynamically revise actions based on execution results. This matters because code can express control flow that is awkward to express through one tool call at a time. A model can loop over files, call functions, parse results, aggregate data, check conditions, and return structured output.

TanStack AI Code Mode makes this pattern more concrete for application tools. Instead of forcing the model through a sequence of individual tool calls, it lets the model write and execute TypeScript programs in a sandbox. Those programs can compose tools, branch, loop, parallelize, and return structured results. TanStack describes the motivation directly: one tool call at a time is the bottleneck.

This is already a form of generative harness, but it is still mostly local. The model generates a small executable structure, and the runtime gives relatively fast feedback. The code may fail to parse, throw a runtime error, time out, call a tool incorrectly, or return a value with the wrong shape. The model can then revise the code. The key point is that the generated structure is small enough that execution feedback is still available.

Claude Code dynamic workflows push the idea to a larger scale. Here the model is not just writing a local program that composes a few tools. Claude can write an orchestration script that coordinates many subagents, intermediate results, and verification passes. The official documentation describes dynamic workflows as scripts Claude writes and can rerun to orchestrate many subagents for codebase audits, large migrations, and cross-checked research; Anthropic’s launch post describes Claude dynamically writing orchestration scripts that run tens to hundreds of parallel subagents in a single session.

That is a qualitatively different boundary. CodeAct makes code the action. Code Mode makes local tool composition programmable. Dynamic workflows make task-level orchestration generative.

The verification gap

The attraction of generative harness is obvious. Complex tasks do not all have the same shape. Some require parallel exploration, some require staged refinement, some require independent critique, and some require a workflow that can collect evidence before making a final claim. If every task has to pass through the same fixed loop, the agent wastes context and time. If every workflow has to be manually designed by a developer, the system cannot adapt quickly enough. Letting the model generate task-specific orchestration is a natural next step.

The problem is that orchestration is harder to verify than action.

A single tool call has local feedback. Did the call succeed? Was the argument valid? Did the file exist? Did the API return data? A code action has execution feedback. Did it run? Did it typecheck? Did the test pass? Did the program return the expected shape? A developer-authored graph can be reviewed before deployment. Its nodes, transitions, and checkpoints can be inspected.

A generated workflow needs a different kind of feedback. Was the task decomposed along the right dimensions? Did each worker receive the right context? Were the right subtasks parallelized? Did the verifier check the real risks, or merely check formatting? Were the completion criteria strong enough? Did the workflow miss an entire class of evidence?

This is what makes generative harness risky. A bad tool call is a local error. A bad code action often fails at runtime. A bad workflow can run successfully and still be wrong.

The failure mode is subtle because the system may not crash. In fact, it may look more convincing precisely because every stage appears to have run. There are workers, intermediate summaries, a verifier, and a final report. The process looks complete, but the structure of the process may never have been validated.

This is where the analogy to AI slop becomes useful, although it should not be the main topic. AI slop is often discussed as low-quality generated content, but its deeper pattern is unverified completion. The output has sections, fluent language, conclusions, and sometimes citations, yet lacks real judgment or evidence density. Generative harness can produce the same pattern at the process level. A workflow may have stages, workers, verification, and a polished final answer, while the orchestration itself is flawed.

In that sense, AI slop is content-level unverified completion. Workflow slop is process-level unverified completion. The same pattern moves from outputs to execution.

Orchestration can fail silently

The reason this matters is that a generated workflow is an amplifier. When the orchestration is right, it can broaden search, parallelize investigation, run independent critiques, coordinate large migrations, and check results before they reach the user. When the orchestration is wrong, it can amplify the wrong assumption across every worker.

A task may be decomposed along the wrong dimensions. All subagents may inherit the same flawed framing. A verifier may check whether the final report is well-formed rather than whether the evidence supports the claim. A workflow may treat “all workers returned” as equivalent to “the task is complete.” The final synthesis may hide disagreement between workers because the summarizer was never instructed to preserve conflicts.

These are not ordinary execution errors. They are orchestration errors. They do not necessarily surface as exceptions, failed tests, or invalid tool responses. They can produce polished, structured, and wrong results.

This is the central tension of generative harness: the model can generate the structure of work before we have a mature way to verify that structure.

Toward verified generative harness

The answer is not to avoid generative harness. Fixed loops are too rigid, and developer-authored graphs cannot cover every task shape. If agents are going to work on open-ended tasks, they will need some ability to synthesize execution structures on demand.

The next step is to make those structures governable. A runtime for generative harness cannot only execute tools and launch workers. It also has to inspect, constrain, and validate the generated orchestration. That means workflow preflight, scope and budget checks, context coverage checks, checkpoint reviews, independent verifiers, trace-based final validation, human approval at structural boundaries, and regression tests for reusable workflows.

The important word here is structural. We already have partial ways to validate individual actions and code execution. What we lack is a strong feedback loop for the shape of work itself. A verified generative harness should be able to answer questions such as: What workflow did the model generate? Why was this decomposition chosen? What context did each worker receive? What evidence supports the final answer? What did the verifier actually verify? Where did the workflow exceed its original scope? Should this workflow be saved, reused, or discarded?

This turns the platform’s responsibility upward. It is no longer enough for the runtime to safely execute a tool call. The runtime must supervise generated orchestration.

Closing

The history of agent systems can be read as a gradual movement of orchestration. In early tool-calling agents, orchestration lived in a fixed loop. In LangGraph, it became explicit and developer-authored. In CodeAct and Code Mode, the model began to generate local executable control flow. In dynamic workflows, the model begins to generate task-level orchestration.

That is the rise of generative harness: agents are starting to write their own execution structures.

The opportunity is obvious. A model that can generate the right orchestration for the task can do more than call tools one step at a time. It can adapt the structure of work to the problem.

The risk is just as important. Orchestration can fail silently. A generated workflow can run, produce intermediate artifacts, invoke verifiers, and return a polished final result, while the task was decomposed incorrectly from the start.

The next bottleneck is not execution. It is verification of generated orchestration.

Generative harness may be the next step, but verified generative harness is the part that will make it reliable.

Product Messages Are Not LLM Messages

Zhuo Jinggang — Fri, 29 May 2026 03:25:06 +0000

Most agent products start from a simple shape:

A user sends something.

The assistant responds.

The app stores the conversation.

That works for a prototype, but it starts to break when the product becomes real. Once an agent supports files, images, tools, approvals, citations, artifacts, resumable streams, long-running tasks, or multiple model providers, the word "conversation" starts hiding two different records.

The first record is what the product needs to store. The second record is what the LLM actually saw. They are related, but they should not be the same stored object.

The product needs a durable record of the user experience: what the user sent, what the assistant displayed, which files appeared, which tools ran, which artifacts were created, which approvals happened, and how the conversation should be rendered, resumed, searched, audited, and migrated. The LLM needs a different record: the instructions, selected history, resolved attachments, tool observations, retrieved facts, provider-specific input parts, model output, token usage, and errors involved in a particular execution.

Those two records serve different systems. They change at different speeds, fail in different ways, and become harder to reason about when they are forced into one message object. The better rule is simple:

Store what the product experienced separately from what the LLM saw.

Or shorter:

Product messages are not LLM messages.

The Hidden Mistake: One Record for Two Worlds

A chat-like interface makes the mistake feel natural. The user sees a sequence of messages, and the model also appears to consume a sequence of messages, so the first implementation often stores one list and uses it for everything.

That list becomes the product history, the model input, the streaming state, the audit log, and eventually the place where tool results, file references, citations, approvals, provider-specific fields, and partial execution state all accumulate. At that point, the message list is no longer a clean product model. It is an accidental mixture of product state and execution state.

This creates problems on both sides. The product record becomes polluted by temporary model concerns: provider-specific content parts, prompt formatting, compressed tool observations, retrieved snippets, model-specific attachment formats, and context-management artifacts. The model input becomes polluted by product concerns: display metadata, timestamps, loading states, preview URLs, frontend editor structures, collapsed panels, UI labels, and other details that exist only so the product can render correctly.

Neither side gets what it wants. The product wants a stable, durable, user-facing record. The LLM wants a focused execution input. Those should not be the same stored object.

Product Messages: What the Product Experienced

Product messages are the canonical record of the conversation from the product's point of view. They should answer questions like:

What did the user see?
What did the user send?
What did the assistant display?
Which files were attached?
Which tool runs appeared in the conversation?
Which artifacts were created?
Which citations were shown?
Which approvals were requested or granted?
Which errors should be visible?
How should the conversation be resumed later?

This record should be durable, renderable, searchable, paginatable, auditable, and migration-friendly. It should preserve stable IDs, timestamps, authorship, message structure, attachment metadata, artifact references, tool progress, approval state, citations, and user-visible errors.

It may also include rich product-specific structure. A user input might be a structured editor document, not just plain text; it might include images, PDFs, spreadsheets, selected workspace objects, mentions, or pasted screenshots. An assistant response might include text, generated files, citations, tool activity, expandable logs, intermediate status, or custom UI blocks.

That richness is not a problem. It is exactly what makes the product useful. The problem starts when this product-shaped record is treated as the LLM's own record. The LLM does not need every display field, timestamp, collapsed panel state, frontend-only metadata, object URL, or internal UI structure.

Product messages should be allowed to stay product-shaped. They are the source of truth for the user experience, not a prompt format.

LLM Messages: What the LLM Saw

LLM messages are different. They are not the canonical conversation; they are the execution record of a specific model run. They should answer questions like:

Which model was called?
Which provider was used?
What instructions were included?
Which parts of the conversation were selected?
Which files or artifacts were resolved?
Which tool definitions were available?
Which tool results were included?
Which retrieved facts or memories were added?
What exact input did the model receive?
What did the model output?
How many tokens were used?
What error or finish reason occurred?

This record is valuable, but for a different reason. Product messages help the app render and resume the conversation; LLM messages help engineers debug, replay, evaluate, compare, and audit model behavior. They are an execution trace.

That trace should usually be immutable. Once a model run has happened, the record of what the LLM saw should not silently change because the product conversation was edited, an attachment preview changed, a context policy was updated, or a provider adapter was refactored.

This is especially important for debugging. When a user asks, "Why did the agent do that?", the product conversation is not enough. You need to know what the LLM actually saw at that moment: maybe an older summary was included, a tool result was compressed, a file was too large and only an excerpt was sent, one provider received a native image input while another received a text fallback, or an approval state was visible in the product but not included in the model input.

Without a separate execution record, these differences are hard to inspect. With one, they become visible.

A Conversation Is Not a Prompt Log

A useful mental model is:

The conversation is product messages.

The prompt log is LLM messages.

They overlap, but they are not the same thing. The conversation is organized around the user experience, while the prompt log is organized around model execution. The conversation should be pleasant to render and stable to evolve; the prompt log should be exact enough to replay and inspect.

The conversation may contain rich product objects, while the prompt log may contain provider-specific input parts. The conversation may be edited, redacted, migrated, or re-rendered, while the prompt log should preserve what happened during a specific run.

This distinction becomes more important as the product grows. A simple text-only assistant may get away with one message list for a while, but an agent product with files, tools, artifacts, permissions, and multiple models needs a stronger boundary. Do not store the product experience as if it were merely a prompt, and do not store the prompt as if it were the product experience.

Why Storage Separation Matters

It is tempting to describe this as a schema preference, but the real reason is operational. The model layer needs stable prepared context. The product layer needs durable user history. Those are different stability contracts.

A naive chat product treats the stored message list as the model context: take the messages in order, append the new user input, and send the whole thing to the model. That is simple, but it makes product history and prepared context collapse into the same thing. Real agent products cannot live with that assumption for long, because the model input has to be selected, resolved, compacted, cached, adapted, and inspected.

Prompt Caching Needs Stable Context

Prompt caching makes this separation concrete. Caching works best when the model input has stable, repeatable pieces: system instructions, tool definitions, long-lived summaries, selected history, resolved artifacts, and other context blocks that can be arranged in a predictable order. If every request is assembled directly from a noisy product message list, small product changes can disturb the cacheable prefix for reasons that have nothing to do with model behavior.

That instability is not a product problem. The product should be free to evolve its conversation model, add display metadata, change attachment previews, update tool event UI, or migrate how artifacts are rendered. It becomes a model problem only when the same stored object is also treated as the context sent to the LLM.

Context compaction has the same shape. A compacted summary may be exactly what the model should see for a new run, and it may even become part of the stable cacheable prefix. But that summary should not replace the original product conversation, and it should not silently rewrite what an older run saw. It is prepared context, not the conversation itself.

This does not mean every model call should be frozen forever. Context still changes when the user asks something new, when a relevant file is added, when a tool result matters, or when the compaction policy produces a better summary. The point is that these changes should be intentional model-context changes, not accidental cache misses caused by UI state leaking into the prompt.

An uploaded image shows the same boundary in a smaller form. The product may keep one stable image card with a file name, thumbnail, permissions, and placement in the conversation. The model context may receive native image input, compressed bytes, a text fallback, or only an artifact pointer depending on the provider and the task. Those are not competing versions of the same field; they are different records with different stability rules.

Old Runs Need Execution Truth

The second reason is historical truth. Imagine looking at an old agent conversation six months later. The product UI has changed, the file preview component is different, the model provider has changed, and the way you prepare context has changed. Maybe the agent now uses a retrieval system or compaction policy that did not exist when the old run happened.

The conversation should still render as the user experienced it, and the model run should still show what the LLM saw at the time. Those are two different promises. If the same stored message object is responsible for both, old conversations become fragile: a harmless UI migration can make model debugging harder, a better context strategy can accidentally rewrite the meaning of an old run, and a provider migration can leave historical data in a shape that is neither good product state nor accurate model state.

Separate records avoid that confusion. The product message says, "This is what happened in the conversation." The LLM message says, "This is what the model saw during this execution." The bridge between them can evolve, but the records should remain honest.

This is the architectural benefit:

Product messages preserve the user experience. LLM messages preserve the execution reality.

Both are important. They just should not be the same record.

The Feeling of a Better Boundary

A good boundary should make the system feel calmer. The conversation can be redesigned without wondering whether a CSS-era field will leak into the next prompt. The model input strategy can change without rewriting old user-visible history. A provider adapter can evolve without mutating the conversation record. A bad run can be inspected without reconstructing the prompt from today's version of the UI.

This is the feeling I want from the architecture:

The product keeps the story the user experienced.
The model run keeps the facts the LLM saw.
The two are connected by IDs, not collapsed into one object.

That is enough. You do not need to turn the product schema into a prompt schema, and you do not need to turn the prompt log into a UI schema. You just need to let the two records stay honest about what they are.

Product Messages Are Not LLM Messages

The mistake is not using the wrong message format. The mistake is using one stored object for two different realities. The product has to remember what the user experienced, and the model run has to remember what the LLM saw. Those are not the same thing.

A conversation is not a prompt log, and a prompt log is not a conversation. The conversation is product messages: durable, renderable, resumable, searchable, auditable, and migration-friendly. The model run is LLM messages: exact, execution-specific, replayable, debuggable, evaluable, and provider-aware.

They should be connected and they should reference each other, but they should not share the same schema. This separation gives the product room to evolve without losing execution truth, gives the model layer room to improve without corrupting the product history, and makes context management and prompt caching much easier to reason about.

The final rule is simple:

Store the conversation the product experienced.

Store the execution the LLM saw.

Link them, but do not collapse them.

That is the difference between product messages and LLM messages.

Killing the "Lollipop": Rebuilding Rotation UX in React Konva

Zhuo Jinggang — Sun, 14 Dec 2025 15:32:19 +0000

When I started building a canvas-heavy product with React Konva, I ran into a UX problem almost immediately.

Konva is powerful, stable, and well thought-out — but its interaction model is old. In particular, rotation is controlled by the classic lollipop handle: a small stick protruding from the bounding box.

That handle no longer exists in modern design tools.

In tools like Figma or Sketch, users have strong muscle memory:

grab a corner to resize
hover just outside a corner to rotate

There’s no visible widget, no extra UI, and no explanation required. Rotation is discovered spatially, not visually.

I wanted that same interaction model in my canvas app. Instead of tweaking Konva.Transformer, I decided to remove it entirely and rebuild rotation from first principles.

This post walks through the architecture and geometry behind that decision — starting from the interaction idea, moving through the type system, and ending with the rotation math itself.

Why Not Customize `Konva.Transformer`?

At first glance, the transformer seems like the obvious place to start. But the real problem isn’t its visuals — it’s its encapsulation.

Konva.Transformer bundles together:

hit testing
cursor logic
rotation math
interaction state

inside Konva’s internal implementation. That makes small UX changes — like where rotation activates or how the cursor behaves — disproportionately hard.

What I wanted instead was:

hit testing that lives in application code
rotation math I can reason about
cursor feedback that actually reflects what’s happening

So rather than fighting the transformer, I ejected interaction entirely out of it.

You can find the whole implementation and try it for yourself:

The Strategy: “Ejecting” Interaction to the Stage

The core idea is simple:

The stage owns all interaction. Shapes are dumb.

Instead of letting Konva manage rotation internally, we listen to onMouseDown, onMouseMove, and onMouseUp on the stage, track interaction state ourselves, and update shape state explicitly.

That immediately raises a question:

What exactly is the user doing right now?

To answer that cleanly, I model interaction as a discriminated union.

Defining Interaction as State

type TransformMode =
  | { type: "none" }
  | {
      type: "rotate";
      center: { x: number; y: number };
      corner: { x: number; y: number };
      base: number;
    }
  | { type: "drag" };

This type does a lot of work:

none means no active interaction
drag means pointer movement translates the shape
rotate carries everything rotation needs:
- the rectangle’s center
- the corner that initiated rotation
- a base angle used for cursor orientation

A useRef<TransformMode> holds the current mode. It changes only on mouseDown and mouseUp.

mouseMove never decides what the interaction is — it only reacts to the current mode.

That separation is crucial.

Hit Testing as a Pure Function

With interaction state defined, the next problem is intent detection.

When the pointer is here — what would happen if the user clicked?

I encode that logic in a single function:

function checkHitArea(
  pointer: { x: number; y: number }
): TransformMode;

This function does no side effects. Given a pointer position, it returns the interaction mode that should activate if the user clicks right now.

It’s used in two places:

onMouseMove → preview intent (cursor changes)
onMouseDown → commit intent (lock interaction state)

That symmetry keeps the mental model clean.

Resolving Drag vs Rotate

There’s a subtle UX edge case:

If the pointer is inside the rectangle but near a corner, users expect to drag, not rotate.

Modern design tools resolve this spatially. Rotation only activates outside the shape.

I replicate that logic by comparing distances to the rectangle’s center:

for (const corner of cornerList) {
  const distToCorner = pointsDistance(pointer, corner);

  const pointerToCenter = pointsDistance(pointer, center);
  const cornerToCenter = pointsDistance(corner, center);

  // Pointer must be farther from center than the corner itself
  if (cornerToCenter > pointerToCenter) continue;

  if (distToCorner <= ROTATE_HOTZONE) {
    return {
      type: "rotate",
      center,
      corner,
      base: corner.base + rectState.rotation,
    };
  }
}

If rotation doesn’t match, I fall back to a point-in-polygon test to detect dragging.

This mirrors how Figma resolves ambiguous intent — and it feels immediately familiar.

Rotation Is About the Center, Not the Corner

Once rotation starts, the math begins.

The key insight is this:

You cannot rotate a rectangle in place by changing rotation alone.

Canvas rotation happens around the shape’s local origin (top-left by default). If you don’t adjust position, the rectangle will orbit instead of spinning.

To get a stable rotation, the rectangle’s center must remain fixed.

Step 1: Measure Angular Delta

We measure how much the pointer has moved around the center, relative to the original corner.

const angle = Math.atan2(pointer.y - center.y, pointer.x - center.x);
const angle2 = Math.atan2(corner.y - center.y, corner.x - center.x);
const delta = (angle - angle2) * (180 / Math.PI);

This delta is the rotation change since the interaction began.

Step 2: Rotate the Top-Left Around the Center

To keep the center fixed, we rotate the rectangle’s top-left point around the center.

Conceptually:

Translate the rectangle so the center is at (0, 0)
Rotate the top-left vector
Translate back

const deltaRad = (delta * Math.PI) / 180;
const cos = Math.cos(deltaRad);
const sin = Math.sin(deltaRad);

const dx = initialRect.x - center.x;
const dy = initialRect.y - center.y;

const newX = center.x + (dx * cos - dy * sin);
const newY = center.y + (dx * sin + dy * cos);

This is the entire trick.

Rotation becomes a pure geometric transformation instead of a Konva side effect.

Step 3: Commit the New State

Finally, we apply both position and rotation together:

setRectState({
  x: newX,
  y: newY,
  width: initialRect.width,
  height: initialRect.height,
  rotation: initialRect.rotation + delta,
});

The rectangle now spins exactly in place — no drifting, no wobble, no surprises.

Cursor Feedback Is Part of the Interaction

Most rotation implementations stop once the math works.

But cursor feedback matters.

Each corner has an inherent orientation, and the rectangle itself may already be rotated. I combine both:

base: corner.base + rectState.rotation

That value feeds into a small hook, useRotationCursor, which:

generates a tiny SVG arrow
rotates it to the correct angle
encodes it as a data URI

As the user rotates the shape, the cursor rotates with it.

This is a small detail — but it’s the difference between something that works and something that feels native.

What This Enables

This demo intentionally leaves out:

resizing
snapping
multi-selection
keyboard modifiers

But the architectural shift is already complete.

Hit testing, interaction state, geometry, and rendering are now orthogonal concerns. Adding resizing doesn’t require rewriting rotation. Snapping doesn’t interfere with dragging.

And most importantly:

The lollipop is gone.

What’s left is an interaction model that matches modern design tools — built on simple math, explicit state, and predictable behavior.

DEV Community: Zhuo Jinggang

Generative Harness: When Agents Start Writing Their Own Execution Structures

From actions to orchestration

The verification gap

Orchestration can fail silently

Toward verified generative harness

Closing

Product Messages Are Not LLM Messages

The Hidden Mistake: One Record for Two Worlds

Product Messages: What the Product Experienced

LLM Messages: What the LLM Saw

A Conversation Is Not a Prompt Log

Why Storage Separation Matters

Prompt Caching Needs Stable Context

Old Runs Need Execution Truth

The Feeling of a Better Boundary

Product Messages Are Not LLM Messages

Killing the "Lollipop": Rebuilding Rotation UX in React Konva

Why Not Customize Konva.Transformer?

The Strategy: “Ejecting” Interaction to the Stage

Defining Interaction as State

Hit Testing as a Pure Function

Resolving Drag vs Rotate

Rotation Is About the Center, Not the Corner

Step 1: Measure Angular Delta

Step 2: Rotate the Top-Left Around the Center

Step 3: Commit the New State

Cursor Feedback Is Part of the Interaction

What This Enables

Why Not Customize `Konva.Transformer`?