ur-agent 1.65.12 → 1.65.14

package/docs/VALIDATION.md

@@ -19,7 +19,7 @@ You need:
 
 ```sh
 ur --version
-# expected for this release: "1.65.12 (UR-Nexus)"
+# expected for this release: "1.65.14 (UR-Nexus)"
 ```
 
 ## 0.1 First-workspace model selection (1.45.4)

package/documentation/index.html

@@ -45,7 +45,7 @@
     <main id="content" class="content">
       <header class="topbar">
         <div>
-          <p class="eyebrow">Version 1.65.12</p>
+          <p class="eyebrow">Version 1.65.14</p>
           <h1>UR-Nexus Documentation</h1>
           <p class="lead">A practical, tutorial-style reference for installing, configuring, automating, extending, and operating UR-Nexus.</p>
         </div>

package/extensions/jetbrains-ur/build.gradle.kts

@@ -7,7 +7,7 @@ plugins {
 }
 
 group = "dev.urnexus"
-version = "1.65.12"
+version = "1.65.14"
 
 repositories {
     mavenCentral()

package/extensions/vscode-ur-inline-diffs/package.json

@@ -2,7 +2,7 @@
   "name": "ur-inline-diffs",
   "displayName": "UR Inline Diffs",
   "description": "Review, apply, and reject UR inline diff bundles from .ur/ide/diffs inside VS Code.",
-  "version": "1.65.12",
+  "version": "1.65.14",
   "publisher": "ur-nexus",
   "engines": {
     "vscode": "^1.92.0"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ur-agent",
-  "version": "1.65.12",
+  "version": "1.65.14",
   "description": "UR-Nexus — autonomous engineering workflow engine (plan, execute, test, verify, document, benchmark, reproduce)",
   "type": "module",
   "packageManager": "bun@1.3.14",

package/technical/04-tools.md

@@ -74,6 +74,29 @@ constraints. Mutually independent tasks with no conflicting shared mutations
 can be delegated together, while dependent or conflicting work stays
 sequential.
 
+The proactive model lifecycle is explicit:
+`TaskCreate` → inspect successful result → `TaskUpdate(in_progress)` → inspect
+successful result → `Write`/`Edit`/mutating `Bash`/worker. Task setup and its
+dependent mutation are never one parallel batch. A feature-rich one-file build
+is non-trivial even if implementation uses one `Write`; classification follows
+the requested outcomes and verification burden, not the file or tool-call
+count. Approved-plan handoffs require task creation as their next
+state-changing action, and Ollama/Kimi receives the same ordered rule in its
+compact tool-discipline section. If earlier tasks are all terminal, the model
+must create a new cohesive outcome or reopen the relevant task before new
+workspace work.
+
+The runtime gate accepts an actionable `pending` or `in_progress` record; the
+stricter model-facing sequence keeps status truthful before work begins.
+`TodoWrite` is the equivalent single-call setup in legacy/headless pools, with
+the selected item already `in_progress`. Partial Task V2 exposure never masks
+an available `TodoWrite`. Bare/simple, REPL-simple, coordinator, custom-agent,
+and override-prompt paths retain a usable planner and capability-aware task
+contract, so the gate never instructs those modes to call a missing tool.
+If a user explicitly filters every planner from a custom tool pool, runtime
+fails closed and tells the user to enable Task V2/`TodoWrite` or explicitly
+disable the gate; it never tells the model to call a tool that is absent.
+
 Task IDs remain strings in storage and tool output. Model inputs for
 `TaskCreate` dependencies and `TaskGet`/`TaskUpdate` identifiers may also use a
 positive safe-integer JSON number; the tool boundary normalizes it to the
@@ -92,6 +115,24 @@ redirection, backgrounding, sandbox overrides, and permission-time rewrites to
 mutating commands fail closed. The preview command remains a Bash side effect
 and still follows normal permission, sandbox, and plan-worker rules.
 
+Control-plane operations that establish or tear down tracking cannot depend on
+an already-actionable task: `TeamCreate`, `TeamDelete`, `TaskStop`/`KillShell`,
+and structured team shutdown/plan-response messages are narrow task-gate
+exceptions. Their own schemas, mode checks, active-member checks, and normal
+permissions remain authoritative. Loading a `Skill` and taking a desktop
+screenshot are read-only wrappers; downstream skill actions, desktop
+click/type, API/database/browser/MCP mutations, and future tools classified
+state-changing at runtime remain task-gated.
+
+Syntax verification has the same task-gate-only separation. A strictly parsed
+`node --check <single-file>` or the bounded HTML checker that reads one file,
+constructs but never invokes its first `<script>` body, and prints only a fixed
+syntax result may run after a task-free one-shot Write. Generic `node -e`,
+additional statements or invocation, mismatched files, flags, redirects,
+expansion, backgrounding, sandbox overrides, and permission-time rewrites do
+not qualify. Node remains non-read-only for Bash permission and sandbox
+purposes, so this compatibility path cannot become a general execution bypass.
+
 Task completion also protects that lifecycle boundary. When the final
 actionable `in_progress` task has a successful `Write`/`Edit`/`MultiEdit`/
 `NotebookEdit` after its recorded start but no later successful inspection,
@@ -117,7 +158,11 @@ Descriptions are optional and are never fabricated from labels. The runtime
 accepts only lossless compatibility forms such as string choices and recognized
 question-text aliases; it does not turn arbitrary prose or flat option rows into
 invented questions. More than four blocking decisions are asked in later
-rounds.
+rounds. The sole presentation-only repair compacts a safe explicit header of at
+most 500 characters to one bounded first-word chip when it exceeds 12
+characters. The question, options, labels, descriptions, previews, metadata,
+and selection mode remain byte-for-byte unchanged. Control/ANSI-bearing or
+grossly oversized headers still fail validation.
 
 One narrow end-turn recovery exists for weak models that clearly attempted this
 tool but failed to emit a native call. On an interactive main-agent turn with
@@ -126,10 +171,11 @@ no existing tool use, the runtime may recover either one canonical
 to invoke `AskUserQuestion`, or one standalone Markdown decision menu with
 exactly one bold question, 2–8 bold labeled options with descriptions, and a
 terminal instruction to select an option. The recovered object must pass the
-live `AskUserQuestion` schema unchanged before the normal tool executor opens
-the UI. JSON repair, truncation, duplicate/ambiguous candidates, casual “A or
-B?” prose, examples, incomplete menus, background workers, headless sessions,
-and unavailable/disabled tools all fail closed.
+live `AskUserQuestion` schema unchanged except for that same deterministic
+UI-header compaction before the normal tool executor opens the UI. JSON repair,
+question/choice truncation, duplicate/ambiguous candidates, casual “A or B?”
+prose, examples, incomplete menus, background workers, headless sessions, and
+unavailable/disabled tools all fail closed.
 
 Answers and annotations are not model input fields. They are accepted only
 during post-permission validation after the interactive UI has returned one

package/technical/09-multi-agent.md

@@ -18,6 +18,13 @@ The main agent can spawn subagents. Built-in agent types
 | `Explore`, `Plan` | built-in read-only search and planning agents; registered in the standard npm bundle so plan-mode instructions never advertise missing worker types |
 
 Ordinary `Agent` subagents do not require experimental Teams/swarm mode.
+Every ordinary worker launch does require successful task setup and an
+`in_progress` parent task first; the exact built-in read-only `Explore`/`Plan`
+plan-mode path below is the only exception. Coordinator mode exposes Task V2
+tools (or `TodoWrite` in a legacy pool) instead of directing workers through an
+unsatisfiable gate. Independent tasks may launch in one worker wave only after
+their task records exist and the tasks actually launching are marked
+`in_progress`.
 Approved-plan handoff checks the actual tool pool, agent-type allowlist, live
 `Agent(type)` deny rules, and active built-in definitions. It can fan out
 independent ready tasks only when a selectable implementation worker remains.
@@ -33,6 +40,10 @@ Custom agents reusing those names, generic agents, teammates, background
 launches, custom working directories, and worktree launches remain mutating and
 task-gated. `TeamCreate` and `TeamDelete` also reject plan mode explicitly;
 team lifecycle state starts only after the plan is approved.
+Outside plan mode, team creation/deletion, structured shutdown responses, and
+emergency `TaskStop` are task-control transitions exempt from the workspace
+task gate so team bootstrap and teardown cannot deadlock. Their tool-specific
+validation still applies, including refusing deletion while members are active.
 
 In the standard bundle, `Explore` and `Plan` receive only `Glob`, `Grep`, and
 `Read`, use `dontAsk` permission mode, and have a second runtime boundary that

package/technical/README.md

@@ -1,6 +1,6 @@
 # UR-Nexus — Technical Specifications
 
-> Audited against the executable source and tests for `ur-agent` v1.65.12.
+> Audited against the executable source and tests for `ur-agent` v1.65.14.
 > Command, tool, flag, provider, and setting claims are checked against the
 > implementation rather than copied from product prose. Release validation
 > keeps this version synchronized and packages the complete `technical/`