@zenera/cli 1.1.47 → 1.1.49

package/dist/batch.d.ts

@@ -1,3 +1,4 @@
+import type { RunIdentity } from '@zenera/neo';
 import type { BatchItem, BatchRequest } from './request.ts';
 /**
  * Many questions, one project, at once.
@@ -34,6 +35,8 @@ export interface BatchOptions {
     readOnly?: boolean;
     keys?: boolean;
     yes?: boolean;
+    /** `--as`: who every item acts for */
+    user?: RunIdentity;
     /** a second home for the combined envelope */
     out?: string;
     json: boolean;

package/dist/batch.js

@@ -228,6 +228,7 @@ async function runItem(item, ctx) {
             memoryDir: ctx.memory,
             memoryReadOnly: ctx.memoryReadOnly,
             keys: ctx.opts.keys,
+            user: ctx.opts.user,
             yes: true,
             // The project's own problems are the batch's, not each item's.
             quiet: true,

package/dist/commands/run.js

@@ -1,6 +1,6 @@
 import * as Projects from '@zenera/engine';
 import { display } from '@zenera/engine';
-import { usageByModel } from '@zenera/neo';
+import { identityFromEnv, usageByModel } from '@zenera/neo';
 import { writeFile } from 'node:fs/promises';
 import { resolve } from 'node:path';
 import { parse } from "../args.js";
@@ -41,6 +41,9 @@ export const run = {
         '  --image <ref>          Use this container image to run commands in.',
         '  --read-only            Take away every tool that can write.',
         '  --no-keys              Do not pass API keys into the container.',
+        '  --as <user>            Act for this user: what `current_user` answers and $ZEN_USER_ID',
+        '                         holds. An email also sets $ZEN_USER_EMAIL. For trying',
+        '                         a project; the Zenera app passes the signed-in user.',
         '  --plain                Never open the TUI. Needs a prompt.',
         '  --theme <dark|light>   Colours for the TUI. Default: auto.',
         '  --out <file>           Put the answer in this file instead of on screen.',
@@ -129,6 +132,7 @@ export const run = {
             model: { type: 'string' },
             image: { type: 'string' },
             'no-keys': { type: 'boolean' },
+            as: { type: 'string' },
             'read-only': { type: 'boolean' },
             yes: { type: 'boolean' },
             plain: { type: 'boolean' },
@@ -201,6 +205,7 @@ export const run = {
             memoryDir: request?.memory ?? (values.memory ? resolve(ctx.cwd, values.memory) : undefined),
             memoryReadOnly: values['memory-read-only'],
             keys: values['no-keys'] ? false : undefined,
+            user: asUser(values.as),
             yes: values.yes || ctx.json,
             disposable: values.disposable,
         });
@@ -236,6 +241,31 @@ export const run = {
 // ---------------------------------------------------------------------------
 // Many shots
 // ---------------------------------------------------------------------------
+/**
+ * `--as`, as the identity a run acts for. Always `local` — saying who you are
+ * on your own machine is a test, not a login. The other fields still come from
+ * `ZEN_USER_*` when exported, so `ZEN_USER_ROLE=viewer zen run --as ann` tries
+ * a role too. Unset, the engine reads the environment by itself.
+ */
+function asUser(as) {
+    if (as === undefined) {
+        return undefined;
+    }
+    const id = as.trim();
+    if (!id) {
+        throw usageError('--as needs a user', 'an id or an email, e.g. --as ann@example.com');
+    }
+    const env = identityFromEnv({ ...process.env, ZEN_USER_ID: id });
+    return {
+        ...env,
+        id,
+        email: env?.email ?? (id.includes('@') ? id : undefined),
+        source: 'local',
+    };
+}
+// ---------------------------------------------------------------------------
+// Many shots
+// ---------------------------------------------------------------------------
 /**
  * Flags that mean something to one run and nothing to a hundred. Refused by
  * name rather than ignored: a `--workspace` that was quietly dropped is a batch
@@ -276,6 +306,7 @@ async function batch(ctx, values, rest, piped) {
         image: values.image,
         readOnly: values['read-only'],
         keys: values['no-keys'] ? false : undefined,
+        user: asUser(values.as),
         yes: values.yes,
         out: values.out,
         json: ctx.json,

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@zenera/cli",
-    "version": "1.1.47",
+    "version": "1.1.49",
     "description": "Command-line front end for @zenera/neo: agentic projects you can run, share and commit.",
     "keywords": [
         "agents",
@@ -54,9 +54,9 @@
         "@google/genai": "^2.30.0",
         "@inkjs/ui": "^2.0.0",
         "@openrouter/sdk": "^1.4.25",
-        "@zenera/engine": "^1.1.47",
-        "@zenera/neo": "^1.1.47",
-        "@zenera/view": "^1.1.47",
+        "@zenera/engine": "^1.1.49",
+        "@zenera/neo": "^1.1.49",
+        "@zenera/view": "^1.1.49",
         "google-auth-library": "^10.0.0",
         "ink": "^7.1.1",
         "openai": "^6.0.0",

package/templates/editor/.github/skills/zen-spec-sync/SKILL.md

@@ -180,7 +180,13 @@ nothing it did not already owe when the last pass verified it.
    path, every changed top-level key in `agents.yaml`, every `SPECIFICATION.md`
    hunk, every answered feedback question and every `Still open` item. A hunk
    counts by what it asks for, not by the section it sits in: a _Scope_ line
-   that introduces writing scripts reaches **code**.
+   that introduces writing scripts reaches **code**. A hunk that only
+   describes what is already built asks for nothing: when the implementation
+   diff is empty and reading the files the hunk names shows they already do
+   exactly what it says, it counts as **specification**. A `✅` entry whose
+   **Still to implement** says nothing is left is the usual source; confirm
+   it by that reading rather than trusting it. One line that differs makes the
+   hunk count by what it asks for.
 2. **Take the union** of the skills and checks those areas name. Load those
    skills and no others. Name each skill and expensive check left out, with
    the reason: `zen-sandbox - no sandbox/, sandbox: or pin change`. Reading
@@ -199,8 +205,9 @@ A full or tampered pass reaches every area.
 ### Areas
 
 - **specification** - wording in `SPECIFICATION.md` or
-  `SPECIFICATION-FEEDBACK.md` that asks for nothing in the areas below. Skill:
-  none. Checks: baseline.
+  `SPECIFICATION-FEEDBACK.md` that asks for nothing in the areas below,
+  including a hunk that only describes what is already built. Skill: none.
+  Checks: baseline.
 - **prompts and grants** - `agents/prompts/**`, `agents/skills/**`, and the
   `tools:` and `skills:` lists of an agent. Skill: none of its own; the content
   may reach another area. A `sandbox:*` or `files:*` grant is a tool grant, not
@@ -341,7 +348,9 @@ feedback or `Still open` item requires implementation work:
 - the pass edits nothing except `SPECIFICATION.md`, `SPECIFICATION-FEEDBACK.md`
   and the `@zenera/*` pin in `sandbox/Dockerfile`
 - no changed specification hunk names an agent, tool, model, embedding, skill,
-  house rule, handoff, memory, index, asset or setup step
+  house rule, handoff, memory, index, asset or setup step - except a hunk that
+  only describes what is already built, confirmed as the plan says, such as a
+  `➕` keep answer folded into the specification
 
 Generated copies and the editor tree repaired by `--fix` are maintenance, not
 project implementation edits for this test.