Confirm before risky actions + engine ambient light & shadows

Install the safeguards before letting go

The more you want to "let the AI work for you," the more you must first answer one question: will it do something it shouldn't while you're not watching? This day's through-line was equipping "letting go" with safeguards — making risky actions require your approval, and making third-party plugins' sources verifiable. At the same time, the workbench went fully plugin-ized, plugins became editable inside the product, and the engine's image quality kept pushing toward realism. Safety, extensibility, good looks — pieces placed in three directions at once; but running through them is one word: trust. Only when you're sure it won't run amok, and that what you install is trustworthy, do you dare truly hand off the work.

A confirmation prompt before risky actions

Agents gained a safety gate when calling tools. Each tool can declare its confirmation policy: always confirm, never confirm, or confirm only when judged dangerous. When an agent is about to take a dangerous action (say, deleting or overwriting an important file), the backend pushes a "needs confirmation" request to the interface in real time, a confirmation bar pops up at the top, and it proceeds only if you allow and is blocked on the spot if you deny; every decision is logged for the record. This gate addresses the most unsettling risk — "the agent quietly finished doing something bad in the background and you had no idea." With it, you get the ease of letting go while always holding final veto over critical actions. This is the concrete landing of the "human is the final authority" principle in the product.

Edit plugins right in the app

A new "plugin author" workbench arrived: a file tree on the left, an editor on the right, changes taking effect immediately. Its significance is dropping the bar for "extending it yourself" to near zero — to tweak a tool's prompt, change a parameter, or try an idea, you don't leave the product, switch to a code editor and shuffle back and forth, but edit right in the interface and see the effect at once. This echoes a long-term direction of the platform: letting non-professional developers, even users themselves, extend and customize the platform hands-on, rather than only using what developers preset. Though for now it's a plain file tree plus edit box, once "you can change the product inside the product" holds, the space of what's imaginable opens up.

Plugins can be signed, verified and trusted

Since the platform is heading toward an ecosystem where "anyone can make plugins and share them," safety must set rules first. This day gave plugin packages a full trust mechanism: a digital signature on export, automatic verification on import to confirm a package truly comes from the author it claims and hasn't been tampered with in transit; the system keeps a trust list recording which sources are trustworthy; and once a source's signature is revoked, freshly installing its plugins is blocked outright. This draws on the mature "signing + chain of trust" approach in software distribution, with a clear aim: when you install someone else's plugin, you needn't trust blindly. An open plugin ecosystem without this trust foundation will sooner or later be bitten by malicious or tampered plugins; establishing it while the ecosystem is still small is the responsible move.

Engine: ambient sky light + shadows + game-scale scenes

The engine's image quality took another step up this day. With image-based ambient light added, objects are softly lit by their surroundings — shadowed areas are no longer dead black, smooth surfaces reflect the environment's color, and the whole scene's light becomes natural and refined; together with the existing directional shadows, the light-and-dark relationship is more complete and believable. More tellingly: this day the engine could load and render a game-scale, complex, large indoor scene in full, with multiple lights lit at once. Running a scene of such real scale is a hard test of a renderer's "real-world readiness" — it means the engine has moved from the "can spin a cube" demo stage into the "can hold up under real game content" stage.

A fully plugin-ized workbench: many tools on one architecture

This day fully plugin-ized the workbench: tools like character, narrative and plugin-author now all run as their own embedded pages on the same split-surface plugin architecture, no longer special cases hardcoded into the main interface. The interface side also changed "which plugins to load" from a hardcoded table to subscribing to a dynamic plugin registry — what's installed is what shows, with no main-program code changes. Chat can also invoke a plugin's capability directly with a /tool command. The far-reaching significance: it puts "built-in features" and "third-party plugins" on the same starting line — the platform's own tools and others' tools follow the same integration rules. Only when a system's core features can themselves exist as plugins does it truly hold the potential to be extended without limit.

What this day means

The keyword of this day is "trust." Risky actions needing your nod and plugin sources being verifiable address "do I dare let it act, do I dare install others' things"; the fully plugin-ized workbench and editing plugins inside the product address "can this platform be extended without limit, can users do it themselves"; the engine adding ambient light and shadows and running real-scale scenes addresses "is what it makes actually good-looking and real enough." Safety, openness, image quality look like three things but all pave the way for one future: a platform you dare truly hand creation to, can keep extending to your own ideas, and that produces presentable work. Only by laying the foundation of trust solidly can you talk about handing greater freedom to users.