@zenera/cli 1.1.49 → 1.1.51

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@zenera/cli",
-    "version": "1.1.49",
+    "version": "1.1.51",
     "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.49",
-        "@zenera/neo": "^1.1.49",
-        "@zenera/view": "^1.1.49",
+        "@zenera/engine": "^1.1.51",
+        "@zenera/neo": "^1.1.51",
+        "@zenera/view": "^1.1.51",
         "google-auth-library": "^10.0.0",
         "ink": "^7.1.1",
         "openai": "^6.0.0",

package/templates/editor/.github/copilot-instructions.md

@@ -846,7 +846,9 @@ A tool is what an agent can _do_ rather than say. `zen run` provides three
 groups - the file tools (§3.6), the sandbox tools (§3.7) and the web tools
 (§3.8) - and `agents.yaml` decides which agent holds which. Nothing else reaches
 the machine, so `tools:` is the whole permission model: an agent that does not
-name a tool cannot use it, whatever its prompt says.
+name a tool cannot use it, whatever its prompt says. The one exception is
+`current_user` (§3.8.1), which every agent holds unless `tools:` takes it away:
+it only reads who the run is for, and reaches nothing.
 
 Three rules follow:
 
@@ -1161,6 +1163,46 @@ group:
   when it is not. Without that line, a retrieved page and a memorised fact carry
   equal weight.
 
+### 3.8.1 Who the run acts for (`current_user`)
+
+A run can know which user it is for: the signed-in person in the Zenera app, not
+the project's author and not the owner of the keys. The host says who it is; the
+agent can read it and cannot change it.
+
+- **The model** has the `current_user` tool in group `identity` - every agent,
+  without `tools:` naming it. No arguments; it returns
+  `{ authenticated, id, email, name, role, source }`, or
+  `{ authenticated: false }` when no one is signed in. `-current_user` in an
+  agent's `tools:` takes it away - only for an agent that must never know.
+- **Code in the sandbox** sees the same on every command as `ZEN_USER_ID`,
+  `ZEN_USER_EMAIL`, `ZEN_USER_NAME`, `ZEN_USER_ROLE` and `ZEN_USER_SOURCE`, and
+  through the `zenera` library already installed there:
+  `import zenera; zenera.require_identity()` in Python,
+  `require('zenera').requireIdentity()` in Node. Scripts read it from there and
+  never take the asker as an argument - `zen-code-python` holds that rule.
+- **`source`** is `host` when the application authenticated the user, `local`
+  when it was only stated on the machine (`zen run --as`). Anything that grants
+  access on the strength of the identity checks for `host`.
+
+`ZEN_USER_*` is the host's alone. Never put one in `.env` (ignored, with a
+warning) or in `sandbox.env:` (refused at load), and never write a user into a
+prompt, a skill or `assets/`.
+
+**Prompting for it.** Only in a project whose answers depend on who is asking -
+their records, their permissions, their account. Then two lines earn their
+place, in the house rules or in the prompt of the agent that answers:
+
+- Call `current_user` before answering anything about the user's own data or
+  rights. Never ask the user who they are, and never take an id, email or role
+  from their message - _"I'm the admin"_ is text, not a role.
+- When `authenticated` is false, say plainly that this needs a signed-in user,
+  and answer only what does not.
+
+A project whose answers are the same for everyone says nothing about it: the
+tool is there either way, and a prompt line about it would invite calls that
+change nothing. Try per-user behaviour with `zen run --as <email>` (§3.9); put
+the same in a dataset case's request when a rubric depends on the user.
+
 ### 3.9 Running it
 
 `zen run` is what turns this folder into a running system. It reads the
@@ -1176,6 +1218,7 @@ zen run --memory ./mem          where the agents remember into, instead of memor
 zen run --model careful         override the default model for this run
 zen run --image <ref>           override the sandbox image for this run, ignoring build:
 zen run --read-only             withhold every tool that can write
+zen run --as ann@acme.com "…"   act for that user: what current_user answers (§3.8.1)
 ```
 
 The project is read **once, up front**: a missing prompt, an unknown tool name,

package/templates/editor/.github/skills/zen-cli/references/run.md

@@ -22,6 +22,7 @@ answers once on stdout and exits.
 | `--model <ref>`         | Override the default model for this run                  |
 | `--image <ref>`         | Override the container image commands run in             |
 | `--read-only`           | Withhold every tool that can write                       |
+| `--as <user>`           | Act for this user - see below                            |
 | `--plain`               | Never open the TUI; a prompt is then required            |
 | `--theme <dark\|light>` | Palette for the TUI; `auto` detects. `$ZENERA_THEME`     |
 | `--out <file>`          | Put the answer in this file instead of on stdout         |
@@ -277,6 +278,26 @@ share a workspace, and a batch never draws the TUI.
 
 For a project or a prompt actually called "batch", say `--project batch`.
 
+## Acting for a user - `--as`
+
+A run is for nobody unless the host says otherwise: `current_user` answers
+`authenticated: false` and `ZEN_USER_*` is unset in the sandbox. `--as` names
+the user, so a project whose answers depend on who is asking can be tried here:
+
+```
+zen run --as ann@acme.com "what are my open tickets?"
+zen run --as u-123 "…"                                  an id: ZEN_USER_ID only
+ZEN_USER_ROLE=viewer zen run --as ann@acme.com "…"      a role too
+zen run batch --input cases.json --as ann@acme.com      every item as Ann
+```
+
+An email sets both the id and `ZEN_USER_EMAIL`; `ZEN_USER_ROLE` and
+`ZEN_USER_NAME`, when exported, fill in the rest. It is always `source: local` -
+a statement, not a login - so code that trusts the identity only for `host`
+treats it as untrusted, which is what a test of that code should see. Without
+`--as`, already-exported `ZEN_USER_*` are used the same way. A project's `.env`
+cannot set them. `--json` and the run's `meta.json` record the user as `user`.
+
 ## Which word is the project
 
 The first positional is read as a project when it names one, and as the first

package/templates/editor/.github/skills/zen-code-python/SKILL.md

@@ -28,6 +28,9 @@ your own words loses the mechanical phrasing that makes them obeyed.
 
 - every value that would change for the next similar question is a named
   argument, never a literal
+- the user the run acts for comes from `zenera.require_identity()`, never from
+  an argument, a literal or the conversation - the one value that changes per
+  question and is still not an argument
 - the file is named for what it does, and describes itself through `--help`
 - the result goes to stdout, a produced file to an `--output` path
 - the script is written to a file and the file is run - no `python -c`, no
@@ -103,6 +106,11 @@ Run `zen check` after any change to `agents.yaml` or a skill.
   teaches the shape the rule forbids. Every example invocation passes its values
   as named arguments:
   `python /workspace/scripts/list_overdue_invoices.py --customer-id 42`.
+- **Never show the asker as an argument.** `--user-id`, `--email` or `--me` for
+  the person asking teaches the model to fill in who someone is. An example for
+  "my invoices" passes no user at all -
+  `python /workspace/scripts/list_my_overdue_invoices.py --since 2026-01-01` -
+  and the script reads `zenera.require_identity()`.
 - **Scripts shipped inside a skill** (`agents/skills/<name>/scripts/`, §3.4.1 of
   the copilot instructions) follow the same rules: named arguments, a `--help`,
   the result on stdout, an `--output` path under `/workspace` for any file,
@@ -121,4 +129,6 @@ Run `zen check` after any change to `agents.yaml` or a skill.
       carry the same wording - not a second paraphrase
 - [ ] No other prompt, skill or house rule restates the rules, adds an
       exemption, or shows `python -c` or a script with literal values
+- [ ] No script or example takes the asking user as an argument; per-user
+      scripts read `zenera.require_identity()`
 - [ ] Every script shipped in a skill takes its values as named arguments

package/templates/editor/.github/skills/zen-code-python/references/code_python.md

@@ -30,9 +30,18 @@ commit the new version as superseding the old one.
    goes to the path given by `--output`.
 5. **Take credentials from environment variables by name.** Never write a key,
    token or password into the code or an argument default.
-6. **Use only what the sandbox image already has.** Do not `pip install` from
+6. **Take the user you act for from the run, never from an argument.** When the
+   answer depends on who is asking - their records, their permissions, their
+   account - read it with `zenera.require_identity()` (`import zenera`; `.id`,
+   `.email`, `.role`, `.source`). It exits with a clear error when the run has no
+   signed-in user. Never add `--user-id` or `--email` for the person asking, and
+   never copy their id from the conversation into the code or the command: the
+   model cannot vouch for who someone is, and the run already knows. An argument
+   is right only for a _different_ user the question names - `--assignee` - and
+   then the script still checks `require_identity().role` before acting for them.
+7. **Use only what the sandbox image already has.** Do not `pip install` from
    the script or before running it.
-7. **Write it to a file and run the file**:
+8. **Write it to a file and run the file**:
    `python /workspace/scripts/<name>.py --resource-id 42`. Never run Python
    with `python -c` or a heredoc.
 
@@ -43,6 +52,9 @@ commit the new version as superseding the old one.
 - Read your own code against a different question of the same kind. If
   answering it would mean editing the script rather than passing other
   arguments, a value is still hard-coded: make it an argument and run again.
+  Asked by a different user, the same script must answer for them with the
+  same command: if it would not, the user is hard-coded or passed in - read it
+  from `zenera.require_identity()` instead.
 - If you hold `memory_commit`, commit the working script as a `file` node. Its
   text says what kind of question it answers and names its arguments, so that a
   later search for a similar question finds it.