@zq-silk/yui 0.12.4 → 0.13.1

package/dist/storage/upgrade/upgradeOrchestrator.js

@@ -589,7 +589,7 @@ async function executeSqliteInPlaceUpgrade(options, classification, now, callerP
                     finally {
                         db.close();
                     }
-                });
+                }, options.externalUpgradeFenceOwnerPid ?? callerPid);
             }
             catch (error) {
                 unexpected = error;
@@ -1358,7 +1358,7 @@ function executeFenced(options, classification, target, callerPid, now, switchSt
                     ? {}
                     : { backupPath: report.switch.backupPath })
             };
-        });
+        }, options.externalUpgradeFenceOwnerPid ?? callerPid);
     }
     catch (error) {
         if (!(error instanceof UpgradeFenceError))

package/dist/storage/upgradeCoordination.js

@@ -37,12 +37,13 @@ const COORDINATION_LOCK_MIN_AGE_MS = 1_000;
  * A hook that passed a check before an upgrade placed its fence either owns the
  * lock and finishes before cutover, or waits and receives an explicit
  * UpgradeFenceError after the cutover holder releases it.  There is no second
- * scan or retry protocol hidden in this helper.
+ * scan or retry protocol hidden in this helper. A staged updater child passes
+ * its already-authenticated parent fence owner through this same boundary.
  */
-export function withUpgradeCoordinationLock(home, execute) {
+export function withUpgradeCoordinationLock(home, execute, fenceOwnerPid = process.pid) {
     const release = acquireUpgradeCoordinationLock(home);
     try {
-        assertUpgradeAdmission(home);
+        assertUpgradeAdmission(home, fenceOwnerPid);
         return execute();
     }
     finally {
@@ -57,8 +58,8 @@ export function withUpgradeCoordinationLock(home, execute) {
  * avoiding a permanent post-promote hook deadlock.  A malformed marker with a
  * missing Home still fails closed because its recovery phase cannot be trusted.
  */
-export function assertUpgradeAdmission(home) {
-    assertHomeWritable(home);
+export function assertUpgradeAdmission(home, fenceOwnerPid = process.pid) {
+    assertHomeWritable(home, fenceOwnerPid);
     const progressPath = switchProgressPath(home);
     if (!existsSync(progressPath))
         return;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zq-silk/yui",
-  "version": "0.12.4",
+  "version": "0.13.1",
   "description": "Local control plane for long-running native agent CLI sessions backed by tmux.",
   "license": "MIT",
   "private": false,

package/skills/yui-leader/SKILL.md

@@ -13,6 +13,10 @@ Own Task direction, decomposition, semantic decisions, acceptance, integration,
 and durable context. The Task is the bounded user outcome. A WorkItem is only
 one substantial, independently acceptable requirement with a distinct owner;
 it is not the default container for every edit, check, finding, or repair.
+For Leader and Operator, this ownership is a default responsibility, not an
+action-permission boundary. The global Operator has the same Task control
+surface and may act directly; always read current durable state and let
+transactional fences resolve races.
 
 Do not invent another execution entity or a `yui ... subagent` command.
 

package/skills/yui-operator/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: yui-operator
-description: Route multi-project user requests into Yui Tasks, configure Yui through confirmed conversation, preserve durable intent, present progress, answer inputs, and administer lifecycle without taking over Leader decisions.
+description: Route multi-project user requests into Yui Tasks, configure Yui through confirmed conversation, preserve durable intent, present progress, answer inputs, and exercise full Task control when useful.
 ---
 
 # Yui Operator
@@ -11,9 +11,11 @@ workspace.
 
 Be the task-neutral user entry point. The user should be able to discuss
 features, bugs, investigations, and questions across multiple Projects without
-managing Yui records. Route each request to the correct Project and Task; leave
-decomposition, execution-path selection, semantic decisions, acceptance, and
-integration to that Task's Leader.
+managing Yui records. Route each request to the correct Project and Task. The
+Leader is the default local coordinator, but between Operator and Leader, Role
+is a responsibility hint rather than an action-permission boundary: the
+Operator may perform any legal Task action when that is the clearest way to
+advance or recover the outcome.
 
 ## Communicate with the user
 
@@ -142,9 +144,9 @@ yui task activate <new-task-id>
 
 Resolve all known Projects before creating repository-backed work. If Project
 identity is ambiguous, ask one targeted question. An active Task may gain
-another Project only when its Leader decides that the repository is required
-for the same bounded outcome; route that request to the Leader instead of
-silently changing scope. Use bare `operator submit` only for a confirmed
+another Project when the Operator or Leader determines that the repository is
+required for the same bounded outcome. Read the current Task state first and
+record the scope change directly. Use bare `operator submit` only for a confirmed
 Gitless mission. It creates a Draft, which may remain Draft while material
 scope is unresolved; activate it once that scope is ready for execution.
 Report the Task ID, Projects,
@@ -154,7 +156,8 @@ separate Tasks merely because it spans several Projects or files. A Task may
 carry many features and rounds of WorkItems toward its shared outcome, but it is
 not a permanent backlog; genuinely independent goals become their own Tasks.
 
-Record Project-defined Task intent and leave execution topology to the Leader.
+Record Project-defined Task intent. The Leader normally chooses execution
+topology, while the Operator may choose or change it when acting on the Task.
 For software Projects, use `--type bugfix` or `--type feature`. A bugfix is
 Leader-owned; if it expands into independently owned delivery requirements,
 the Leader reclassifies it as a feature before creating WorkItems. For a
@@ -240,9 +243,10 @@ For work that does not need Git, create a Task without `--project`.
 Profiles are versioned, provider-neutral Worker behavior templates. A Task Role
 is a mutable Task-bound Worker instance with one or more Agent bindings and
 per-binding runtime configuration. A WorkItem is the only bounded work record.
-Do not pre-split WorkItems or decide their dependsOn, execution path,
-acceptance, or Integration; the Leader owns WorkItem creation, replacement,
-parallel dispatch, dependency and conflict resolution inside the one Task.
+Avoid unnecessary WorkItems. Either Operator or Leader may create, replace,
+dispatch, accept, integrate, and resolve dependencies or conflicts inside the
+Task; use current durable state and the command's consistency fences to avoid
+duplicate or conflicting decisions.
 
 The Leader chooses among direct execution, native subagents, and a Task Role
 AgentRun. Native subagents are created inside the Leader Session, inherit the
@@ -341,8 +345,10 @@ the workflow without claiming that version was delivered.
   such as a Run's terminal state, a committed Integration, or a runtime version,
   read the state and report it; never ask the user to confirm "continue" as a
   scheduler for machine-observable progress.
-- Do not decide code, semantic, requirement, acceptance, or integration
-  conflicts on the Leader's behalf.
+- Prefer the current Leader's coherent plan when it remains valid, but do not
+  treat it as a permission boundary. The Operator may make code, semantic,
+  requirement, acceptance, recovery, and integration decisions and must leave
+  the real actor and rationale in durable Task state.
 - Reconcile a disappeared native Session with `task reconcile`; inspect the Run
   before retrying a confirmed failure.
 - If the current Provider Conversation cannot continue, use