add prompts to avoid having the widget send raw code

app/L0/_all/mod/_core/spaces/ext/skills/space-widgets/SKILL.md

@@ -1,4 +1,4 @@
----
+_---
 name: Space Widgets
 description: Create, patch, inspect, and remove widgets in the current space
 metadata:
@@ -71,13 +71,28 @@ staged turns
 - If `Current Space Widgets` or `_____framework` already showed the widget id you need, skip another discovery call and move to the next step
 - After readWidget() or seeWidget(), patch on the next turn, not in the same JS block
 - After patchWidget(), renderWidget(), or reloadWidget(), use the refreshed Current Widget on the next turn if another edit is needed: `rendered↓` for what mounted and `source↓` for the next patch
+- Never answer with raw JS or a code fence after a widget error. Either send a proper execution message or a normal user-facing answer
+- If you receive an error from patchWidget() that is not a problem in the underlying code, consider fixing the widget with a renderWidget() call
+- If you receive an error from a renderWidget() or patchWidget() call.  Summarize the error and attempt to rerun with the error fixed.  Repeat up to 3 times before giving up
 - Start every execution block with one short sentence saying the immediate step
-- Put that sentence on its own line. Then put _____javascript alone on the next line
+- Put that sentence on its own line. Then put `_____javascript` alone on the next line separated from other text by newlines
+- If the prompt asks you to change, fix, or modify the widget, you should wrap any output code in a patch and render instruction and output in a solitary `_____javascript` block.  Do not merely state the fix.
+- If the response to an error correction emits corrected code, use this code to patch or render the widget.
 - Do not execute silently
-- Do not send only a staging sentence such as Checking widget source or Loading widget source. If you announce a widget read, list, patch, reload, or render step, the same message must execute it
+- Do not send only a staging sentence such as checking widget source, loading widget source, patching the widget, rendering the widget, or fixing the widget. If you announce a widget read, list, patch, reload, render, or fix step, the same message must execute it
+- Do not send only a code change without applying it to the widget unless the user specifically asks for the change not to be applied.
 - After a successful patch or render that satisfies the request, stop and answer normally. Do not keep making more visual tweaks unless the user asked for another iteration or the runtime reported failure
 - After a successful patch or render, the next assistant turn should usually be the final user-facing answer. Do not output another promise line such as Updating... or Applying... without execution
-- Never answer with raw JS or a code fence after a widget error. Either send a proper execution message or a normal user-facing answer
+- After a successful patch or render, do not output raw javascript, html, or css code in the final user-facing answer
+- Never output raw html or css code in user-facing answers, unless the user specifically requests to see code
+- Never output raw javascript code in user-facing answers unless the user specifically requests to see code; otherwise all javascript code should be in a solitary `_____javascript` block
+- `_____javascript` must appear only once and be on its own line
+- Always prepend `_____javascript` or `_____framework` or `_____transient` or `_____user` with a line break so that they begin a new line
+- Always append `_____javascript` or `_____transient` with a line break so that any following text is on a new line
+- The tags `_____javascript` or `_____framework` or `_____transient` or `_____user` should never appear on the same line
+- Any widget modifying requests must result in a patchWidget or renderWidget call- no raw code snippets
+- Any widget modifying requests that returns a successful response must call patchWidget or renderWidget to apply the code changes - no successful response without a code change
+
 
 examples
 Checking widget catalog
@@ -100,13 +115,68 @@ User asked for the snake widget, reading it directly
 _____javascript
 return await space.current.readWidget("snake")
 
+Rendering a widget
+_____javascript
+return await space.current.renderWidget({...
+})
+
+Patching a widget
+_____javascript
+return await space.current.patchWidget("snake-game", ...)
+
+bad
+javascript
+return await space.current.renderWidget({
+
+replace with
+_____javascript
+return await space.current.renderWidget({
+
+
+bad
+Checking the current widget source
+
 bad
+Checking the current widget source_____javascript
+
+replace with
 Checking the current widget source
+_____javascript
+
+bad
+Checking the current widget source_____javascript return
+
+replace with
+Checking the current widget source
+_____javascript
+return
 
 bad
 _____javascript
 return await space.current.readWidget("snake-game")
 
+bad
+_____javascriptreturn await space
+
+replace with
+_____javascript
+return await space
+
+bad
+_____javascriptreturn await space.current.renderWidget({
+
+replace with
+_____javascript
+return await space.current.renderWidget({
+
+bad
+_____framework execution success↓_____javascript return await
+
+replace with
+_____framework execution success↓
+_____javascript
+return await
+
 bad
 Which widget should I change?
 
@@ -123,6 +193,20 @@ return await space.current.patchWidget("snake-game", ...)
 // success came back
 return await space.current.patchWidget("snake-game", ...)
 
+bad
+return await space.current.patchWidget("snake-game", ...)
+
+replace with
+_____javascript
+return await space.current.patchWidget("snake-game", ...)
+
+bad
+return await space.current.renderWidget({
+
+replace with
+_____javascript
+return await space.current.renderWidget({
+
 bad
 Updating the snake widget background now
 Applying the color edits now
@@ -136,8 +220,10 @@ patch vs rewrite
 - find must be one exact unique snippet copied from readWidget() output or from Current Widget `source↓`
 - Omit replace on a find edit to delete that snippet
 - Line-edit shape also works: [{ from, to?, content? }]
+- Line-edit shape patches must include a from
 - from and to are inclusive zero-based renderer line numbers
-- Omit to to insert before from
+- to must be an integer greater or equal to from
+- the content of the patch should go into content and not to
 - Omit content on a ranged line edit to delete
 - Common line aliases like line, startLine/endLine, range, text, and replace are tolerated, but prefer the canonical shapes above
 - Do not mix exact find edits and line edits in the same call
@@ -190,6 +276,11 @@ renderer rules
 - Return a cleanup function if you attach listeners, timers, or other long-lived effects
 - Do not patch unrelated page DOM
 - Do not use global plain-key listeners that interfere with chat. Require widget focus or use modified shortcuts
+- Do not emit raw javascript code that calls a method of space.current. Any such code should be in a  `_____javascript` block
+- Where there are code changes for the widget, wrap the code in a patchWidget() or renderWidget() call
+- Do not emit raw javascript code which is unwrapped
+- When asked for code changes, do not output the raw javascript code but rather generate the patchWidget() or renderWidget() call used to modify the code
+- Requests to modify or change the widget should cause the widget to be patched or rerendered rather than only emitting raw javascript code
 
 flow
 1. listWidgets() if you need the live catalog