@jc_stack/ez-agents 0.1.0-beta.25 → 0.1.0-beta.27

package/.env.example

@@ -26,7 +26,7 @@ EZ_EXECUTOR_CLI=agy
 # OPENCODE_MODEL=openrouter/nvidia/nemotron-3.5-lightning
 
 # Interactive Codex CLI context limit; native compaction preserves the session.
-EZ_CODEX_AUTO_COMPACT_TOKENS=64000
+# EZ_CODEX_AUTO_COMPACT_TOKENS=64000
 
 # Automatic core/plugin repair mandate. Set in deployment docker.env for Compose.
 # Does not grant GitHub access, merge or publication permissions.

package/AGENTS.md

@@ -11,6 +11,14 @@ Installed runtime operation uses Docker Compose. Read
 [Docker setup, state and QA](docs/docker-runtime.md). Docker owns relay/plugin services; the existing host CLI and login are shared
 through one generic transport, with separate agent workspaces and sessions.
 
+## General core instructions
+
+When the owner refers to "general core instructions", they mean
+`templates/agent-guidance.md`, loaded from the installed package into CLI and
+desktop agent runs, including background tasks. Update that file for defaults
+that must reach all agents after upgrade. Workspace `AGENTS.md` files and
+`templates/agent/` seeds alone do not propagate changes to existing agents.
+
 ## Installing this package
 
 When the user asks to set up or install this repository or package, follow
@@ -37,14 +45,13 @@ This package will be published as an open-source, lightweight Telegram-to-CLI re
 - **Native Node 22+ APIs only:** Use `node:fs/promises`, `node:child_process`, `node:crypto`, `node:path`, and native global `fetch`, `FormData`, and `Blob`.
 - Keep `node_modules` minimal and installable in seconds.
 
-## 2. Zero Deterministic Coding Across the Board (Tools, Flows & Dialog)
-- **The relay is dumb plumbing:** The relay only ingests messages, batches them into runs, spawns the CLI executor, and drains outbox items. It is strictly minimal.
-- **Nothing deterministic—not just dialog:** Do not hardcode multi-step tool pipelines, fallback state machines, parameter translation shims, procedural dialog flows, or canned conversational receipts ("Started run...", "I'll message as I go...").
-- **The debugging reflex trap:** When an integration, tool, or flow doesn't work as expected, developers and LLMs have an overwhelming reflex to patch it by writing deterministic procedural code (`if error X -> hardcode Y -> do Z`). **Resist this completely.**
-- **The real engineering work:** Our job is solely to:
-  1. Build clean, standalone tools that work reliably with clear Unix interfaces (clear args, predictable stdout/stderr, clean exit codes).
-  2. Ensure tools have simple setup and are clearly explained in the agent's workspace so the **agent understands them**.
-  3. Let the agent own all flow orchestration, tool chaining, decision making, and error recovery. Question every line of code—if it can be agentic, keep code out of it.
+## 2. The engine is the core; ez is an ultra-lean gate
+- The selected CLI/GUI engine owns intelligence, context, reasoning, planning, goals, delegation and continuation. ez mainly authorizes inputs, invokes engines/tools and transports results. Keep necessary queue ownership, cancellation, secret isolation and reliable delivery deterministic.
+- Plugins are ordinary CLI tools with explicit inputs, outputs and errors. Packaging a tool does not justify another LLM worker or business workflow owner.
+- **SUBTRACT is as valid as ADD.** Question the requirement; delete unnecessary behavior; simplify; shorten feedback; automate last. Name and try the subtraction option before proposing additions. Removing a wrapper or correcting existing engine instructions/tool contracts can be the complete fix.
+- Add code only for a demonstrated missing transport or tool capability. Prompts, agents, retries and lifecycle owners also count as machinery; do not replace deleted code with a scripted prompt workflow. Prefer existing engine, CLI and Docker capabilities.
+- `/goal do my daily routine` is literal task-prompt text for the engine. ez does not parse it, construct a native objective or own its workflow.
+- Keep changes focused. State what was removed, why anything added is necessary, and which observed outcome proves the simpler system works. Preserve authority and uncertain-delivery safeguards. Unchanged, non-actionable maintenance stops quietly; queued updates and passing tests alone do not prove an installed fix.
 
 ## 3. Crash-Safe Atomic Disk State
 - All persistent stores (`ControlStore`, `RunStore`, outbox queue) must be disk-backed JSON files.

package/CHANGELOG.md

@@ -1,5 +1,24 @@
 # Changelog
 
+## 0.1.0-beta.27
+
+- Pass literal task input and `/goal` requests to the selected engine; remove
+  workflow prompt assembly and transport-owned goal creation.
+- Slim shared instructions and discover installed plugin guidance on demand.
+- Let engines own concurrent execution instead of reserving shared workspaces
+  for entire runs. Preserve authorization, request ownership and cancellation.
+- Clarify chat delivery and acknowledgement through the bound message CLI,
+  and decode inline newline escapes in messages.
+- Show active scheduled-task details and simplify AI selection in Telegram.
+- Stop self-feeding maintenance and keep optional transport failures isolated.
+
+## 0.1.0-beta.26
+
+- Start local software-maintenance wakeups in independent ephemeral sessions,
+  including after a relay restart, without trying to resume or persist a
+  normal owner conversation. This prevents successful upgrades from producing
+  false "failed to start" notifications across direct relays.
+
 ## 0.1.0-beta.25
 
 - Enable Codex Luna `max` reasoning for durable work, schedules and deferred

package/CONTRIBUTING.md

@@ -8,7 +8,9 @@ repository. Public docs describe shipped behavior and explicit limitations.
 1. Start one coherent change in a dedicated worktree from fetched origin/main,
    following the isolated-work rules below. Preserve unrelated work.
 2. Install Node 22+ and pnpm 10.30.3. Run `pnpm install --frozen-lockfile`.
-3. Change the code, user instructions and focused tests together. Authority,
+3. Apply AGENTS.md’s KISS change gate: identify the failed boundary, remove
+   unnecessary behavior first, and explain why remaining code is needed. Change
+   the code, user instructions and focused tests together. Authority,
    paths, credentials, cancellation and uncertain writes need negative tests.
 4. Run `pnpm verify`, `npm run release:check` and `git diff --check`.
    Packaging/runtime changes also need the Docker checks in docs/releasing.md.

package/README.md

@@ -120,8 +120,9 @@ does not receive their executor or provider credentials.
 
 Telegram `/status` shows the running relay and host versions plus installed
 plugin versions. Its read-only **Scheduled tasks** control lists the paired
-owner's saved task titles, instructions, timing, state and next run; it never
-creates, changes or runs a task. The agent's `ez status` adds verified plugin
+owner's active schedules in alphabetical order, with their engine/model/effort,
+next occurrence or current queued/running state, and a short preview of the
+saved invocation prompt; it never creates, changes or runs a task. The agent's `ez status` adds verified plugin
 runtime states and upgrade job receipts. See [status and upgrades](docs/upgrades.md).
 
 ## You are the installing agent
@@ -205,8 +206,8 @@ restart and shutdown. The installing agent registers the small host CLI transpor
 
 The selected host CLI runs in this agent's persistent workspace and owns its
 Markdown/work files. New conversations and AI changes preserve those files.
-`AGENTS.md`, `SOUL.md`, `USER.md`, and `TOOLS.md` are seeded; `MEMORY.md` is
-optional. Received files go in `inbox/`, tasks and deliverables in `work/`.
+`AGENTS.md`, `SOUL.md`, and `USER.md` are seeded; `MEMORY.md` is
+optional. Installed plugin snippets and skill paths come from `ez tools list --details`; no tool inventory file needs maintenance. Received files go in `inbox/`, tasks and deliverables in `work/`.
 Credentials and control state stay outside the mind. File separation is not
 OS isolation against a process running as the same user.
 

package/docs/architecture/ai-selection.md

@@ -28,8 +28,11 @@ offer their own default only in this slice. Refresh by opening the native client
 the relay does not install models, manage subscriptions or guess aliases.
 
 Setup initialization and relay startup seed one default choice per installed client.
-Choose AI opens the available installed-model catalog directly; Settings keeps
-saved choices and Refresh available AIs repeats default discovery. Active/default
+Choose AI shows the three most recent valid choices and installed clients, then
+the selected client's models and reasoning levels. Selecting a model and reasoning
+level applies that choice immediately. The retired Settings control points to
+Choose AI; application-backed channels keep these controls in their application.
+Refresh available AIs repeats default discovery. Active/default
 presets and queued snapshots are preserved; discovery only refreshes unused
 detected entries.
 Codex uses its native `config/read` interface; Grok reads its documented user
@@ -38,17 +41,11 @@ workspace JSON settings; OpenCode reports resolved config. Unknown defaults and
 opaque wrappers remain explicitly “client default”. No credentials are stored,
 no inference runs, no new dependency, and no cross-CLI session transfer.
 
-New Codex CLI and desktop agents seed **Responsive chat** (`gpt-5.6-sol`,
-`medium`). Durable work keeps its independent `gpt-5.6-luna` / `max` default;
-workers can explicitly select another model and effort for the job. Native
-choices for other executors remain unchanged. No fallback is selected when a
-model is unavailable.
+New agents leave model/effort unset for native configuration to resolve. Captured
+and explicitly saved choices are preserved; schedules inherit the selected engine
+settings unless overridden. There are no hardcoded chat/worker models or reasoning
+caps. Explicit OPENCODE_MODEL remains supported.
 
-Upgrades add the responsive preset to the menu without changing an existing
-selection, default, session, or queued run. Choose it through Choose AI for the
-current conversation or Settings for future conversations. `/status` shows the
-saved selection. Legacy client-default seeds still use native configuration
-metadata for display only.
-
-See [responsive channels](../responsive-channels.md) for the conversational
-policy and the separate boundaries for plugin correspondence and app backends.
+Restricted sessions intentionally ignore unrestricted user configuration and use
+isolated native defaults when no choice is supplied. See [responsive channels](../responsive-channels.md)
+for their scoped tool and authority boundaries.

package/docs/docker-runtime.md

@@ -153,3 +153,12 @@ its polling delay in executor duration; it is not a pure model-inference measure
 Delivery processing includes pacing, media preparation and provider calls. A sent
 message may precede executor exit. No prompt, message body or credentials are added
 to these timing logs.
+
+### Polling faults
+
+Permanent errors escaping Telegram setup/polling (including unauthorized tokens,
+competing pollers and programming errors) stop relay-level retry until explicit
+restart after repair. Existing authorized work and outbox draining remain active;
+polling health remains unhealthy. Transient HTTP, rate-limit and server errors
+may reconnect. grammY still owns reconnect behavior inside its poller; ez does
+not override private library methods or implement a replacement poller.

package/docs/host-service.md

@@ -88,12 +88,9 @@ preserving it rather than reverting to a different or expired host login.
 
 An agent binding may set `sharedWorkspace` to an absolute canonical application
 repository. The host resolves its canonical path, adds that directory to Codex
-write permissions for chat and scheduled jobs, and serializes all bindings in
-that host executor which share it (including symlink aliases). Task sessions and
-artifacts remain isolated. This is useful when independent task folders still
-write the same application records. Long jobs can delay chat execution; relay
-intake and cancellation remain available. The binding is host-owned and cannot
+write permissions for chat and scheduled jobs, including symlink aliases.
+The host claims requests independently; a running job does not block another
+request sharing its workspace. The selected engine owns execution concurrency.
+Task sessions and artifacts remain isolated. The binding is host-owned and cannot
 be supplied by a queued request. Other executors keep their native filesystem
-policy. This lock is scoped to one host executor process; it does not coordinate
-separate deployments or external writers. Do not run a second controller against
-that repository.
+policy. Shared workspace access does not provide exclusive file ownership.

package/docs/local-qa.md

@@ -20,7 +20,7 @@ package version and `ezQa` provenance metadata differ from the source npm packag
 Do not publish these private archives. Each new candidate gets a new label and a
 version newer than the PA's installed version; labels are never overwritten.
 
-Add the catalog path and the following instructions to the PA's local TOOLS.md:
+Add the catalog path and the following instructions to the PA's local policy file, linked from AGENTS.md:
 
 > When the owner requests a beta number, first inspect the matching beta-N entry
 > in the local QA catalog. Read manifest.json and QA.md. Check the archive SHA-256

package/docs/plugins.md

@@ -28,7 +28,7 @@ Without `--catalog`, init loads an empty packaged catalog. Keep it empty for
 initial main onboarding; no sibling repository, broker or provider account is
 needed. Finish owner pairing and verify an actual Telegram agent reply first.
 Init creates a private registry and `tools/bin/ez`, adds a
-TOOLS.md discovery entry, and binds the matching host executor to that bin
+managed AGENTS.md registry locator, and binds the matching host executor to that bin
 folder. Native binaries are linked through; an existing `ez` collision fails.
 Run before starting the host executor. For an already running installation,
 place a symlink to the returned launcher in that agent's existing private bin
@@ -294,3 +294,16 @@ disabled for that source. Enable the normal shared embedding worker through
 and original readback from the actual executor. Document any differences between
 indexed snapshots and current originals; do not replace Library with private
 QMD runtimes or edit installed Compose/package files to bypass missing support.
+
+## Generated capability discovery
+
+`ez tools list --details` generates a compact index directly from installed
+`ez-plugin.json` manifests: each plugin supplies its `description`, command aliases
+and `skills`. Descriptions are limited to 200 characters in this view; full
+instructions stay in the skill. Installation, replacement and removal are reflected
+on the next read, without hooks, LLM calls or a cached inventory file.
+
+`ez tools list` retains its alias mapping for existing clients. Native AGENTS.md
+contains only the agent-bound discovery shortcut. New workspaces do not seed
+TOOLS.md; upgrades preserve legacy notes without rewriting them. Keep owner/account
+policies in agent instructions or linked policy files, separate from plugin metadata.

package/docs/releasing.md

@@ -17,8 +17,9 @@ separate release bot is not required.
 3. Build both Docker targets from a clean checkout:
    `docker build --target test -t ez-release-tests .` and
    `docker build --target runtime -t ez-release-runtime .`.
-   Main: `EZ_RELAY_IMAGE=ez-release-runtime node docker/smoke.mjs`.
-   WhatsApp: `EZ_WHATSAPP_IMAGE=ez-release-runtime node docker/smoke.mjs`.
+   Main relay: `EZ_RELAY_IMAGE=ez-release-runtime node docker/smoke.mjs`.
+   The WhatsApp Compose overlay has no separate relay image; verify its
+   provider integration with the synthetic plugin smoke in `docs/plugins.md`.
 4. Create an artifact with `npm pack --ignore-scripts`. Inspect its file list,
    hash it, extract into a fresh directory, copy `docker/pnpm-lock.yaml` to
    `pnpm-lock.yaml`, and run `pnpm install --frozen-lockfile`.

package/docs/repair.md

@@ -1,41 +1,42 @@
 # Native repair ownership
 
-Every deployed agent is a repairer by default. When an agent finds a core or
-plugin defect, it keeps the context and pursues a tested contribution PR. The
-core injects the same mandate into CLI/native and desktop execution, including
-existing workspaces; it does not replace the agent's mind or implement a repair
-workflow engine. Use native Git/GitHub CLI or the installed GitHub plugin.
+Repair is a capability used by an explicit owner request or owner-saved maintenance
+mandate. Discovering a defect alone does not enroll an ordinary conversation in
+an issue/claim/PR workflow. Preserve useful evidence and continue the requested
+task. The current execution guidance supersedes older default-repair text in
+existing workspaces without rewriting the agent's mind.
 
-The agent searches for the same cause, registers a sanitized issue, requests a
-claim, then works in an isolated contribution checkout after the coordinator's
-grant. It resumes the same issue/branch/PR after interruption. The installed
-runtime is never the repair checkout. Missing credentials or coordination remain
-recorded blockers; the default does not invent repository access. Public reports
-must exclude private runtime data and use the security reporting route when needed.
+For an authorized repair, use the selected engine with native Git/GitHub tools
+and follow the target repository's CONTRIBUTING.md. Check existing work for the
+same cause and use an isolated contribution checkout; never edit the installed
+runtime as the repair checkout. Resume the same branch/PR after interruption.
+A separate issue, claim service or coordinator grant is not an ez prerequisite.
+Use coordination only where the repository or owner explicitly requires it.
 
-One coordinator grants claims sequentially per repository. Assignment alone is
-not a lock. All participating agents must use that coordinator; this convention
-cannot prevent an unrelated public contributor from opening a competing PR.
-The discovering agent remains the repairer, including when its work moves to a
-background task. The coordinator reconciles duplicates and stalled claims. The
-maintainer independently reviews and tests, then merges/publishes only within
-separate owner-approved policies. Start from templates/maintainer-purpose.md.
+Question the failing wrapper before adding code. Removing behavior or correcting
+existing instructions/tool contracts can fully resolve the defect. Preserve
+useful evidence and verified outcomes, with normal independent review and CI.
+Missing credentials block only operations requiring them; continue useful local
+work and report the precise remaining dependency. Public reports must exclude
+private runtime data and use the security reporting route where appropriate.
+Do not repeatedly check an unchanged dependency.
 
 ## Disable
 
 Set `EZ_REPAIR_ENABLED=false` in the deployment's Docker environment and recreate
 the relay. The resolved setting crosses the host transport and is included in
 every new execution prompt; the default is true and invalid values fail startup.
-This changes the automatic mandate, not filesystem/GitHub permissions, and does
+True makes the capability available; it does not itself grant a repair mandate.
+The setting does not change filesystem/GitHub permissions and does
 not cancel an already running task. Explicitly stop active repair work when needed.
 An owner can also disable repairs globally or for a repository in the agent's
 saved USER.md preferences; carry those restrictions into background task context.
 
 ## Setup boundary
 
-The shipped mandate and maintainer purpose do not provision a GitHub account,
-coordinator service or publishing token. Enroll the allowed repositories and
-configure one maintainer execution lane on the owner's host before unattended
-claims. Reuse authenticated GitHub CLI where authorized. Repository push and PR
-permissions are distinct from package-registry publication and protected-branch
-approval. Never put credentials in prompts, issues or test environments.
+Reuse existing authenticated access within the owner's request or saved mandate.
+ez does not provision a coordinator, GitHub identity or publishing token, and
+none is an implicit prerequisite for local diagnosis or an authorized local fix.
+Repository push/PR access, protected-branch review and package publication are
+separate capabilities and permissions. Follow existing release authority; never
+put credentials in prompts, issues or test environments.

package/docs/responsive-channels.md

@@ -1,57 +1,15 @@
 # Responsive channels
 
-Ez treats conversational channels as places to answer, clarify and hand off
-work. A simple question uses the current conversation; a small authorized action
-uses its canonical receipt. Substantial work gets a durable task with enough
-context to finish and verify the job. The agent returns to conversation after
-the handoff is saved, instead of waiting for the worker. This is agent guidance,
-not a keyword classifier, automatic acknowledgement, or latency guarantee.
-
-New Codex agents use Sol / medium for chat. Scheduled work defaults independently
-to Luna / max; the agent can choose another model and effort for complex work.
-`ezenciel-agents-schedule create --now --text-file FILE --model MODEL --effort max`
-uses the existing scheduler (include `--name` for a useful task label). Busy owner
-reply sessions expose the same independent model/effort choice through `defer`.
-Its retry returns the first saved schedule; changing arguments does not revise
-an accepted job. `xhigh` and `max` are available only for Luna; other models remain capped at high.
-
-A handoff includes the objective, relevant context and paths, constraints,
-authorized actions, acceptance checks and delivery destination. Background
-sessions own verification and final delivery, and may use native subagents.
-One writer per workspace still applies. Shared external resources require
-coordination even when task directories differ. Status must distinguish a saved
-schedule from actual execution and a verified result from a process exit.
-
-The package loads `templates/chat-guidance.md` at each turn for CLI, desktop,
-busy owner replies and approved plugin messaging tasks. Upgrades refresh this
-behavior without rewriting the agent's personal files. Existing model choices
-remain pinned; an upgrade adds Responsive chat as an available selection.
-
-## Channel and authority boundaries
-
-Telegram owner conversations can schedule work under the owner's authority.
-The existing restricted busy-reply session keeps Codex chat available while a
-writer is active. Other executors retain their existing concurrency behavior.
-
-WhatsApp and other plugin contacts use the approved messaging task's isolated
-context and tools. They receive the conversational guidance and Sol / medium
-selection, but cannot invoke owner schedules, shell tools or native subagents.
-They report work outside their capabilities to the owner; that report is not
-an instruction or permission to execute. Full delegation from a plugin contact
-needs an explicitly scoped worker capability and return route; this update does
-not grant one. The plugin name alone never confers owner authority.
-
-An application using `channelBackendUrl` owns its conversation, model and job
-lifecycle. The relay does not inject prompts or override the app's model. Such
-backends (including AI Fit) must adopt the same handoff policy in their own
-runtime to benefit. Reuse their canonical job system; do not create a second
-agent in the transport. Telegram polling and app-side queue waits still count
-toward user-visible latency.
-
-## Verification
-
-Tests cover independent worker settings, preserved selections across upgrades,
-idempotent handoffs, invalid settings, revocation and restricted tool boundaries.
-Existing scheduler/host tests cover a conversational reply while work remains
-active. Measure time to the first useful reply and verified task completion
-separately on the deployed provider before claiming a performance improvement.
+Owner input passes unchanged to the selected engine. The agent decides when to
+delegate or schedule long work to remain available. ez queues foreground input
+while a foreground run is active; it does not create a separate busy-reply agent.
+Independent scheduled task directories retain deterministic writer isolation.
+
+Background tasks receive literal task text. Their directories contain no generated
+role instructions or copied identity files; native workspace instructions and
+existing Markdown provide context. The agent chooses what to read and when to use
+the message CLI. Native final text is not automatically delivered to Telegram.
+
+Restricted correspondence receives a typed activation event and scoped tools.
+Authorization, sandboxing and tool handlers enforce contact and lifecycle limits.
+Maintenance and group notifications carry event data; CLI help owns operations.

package/docs/scheduling.md

@@ -32,30 +32,26 @@ the host changes zones. Nonexistent DST wall times are skipped; repeated wall
 times fire once, at the earlier instant. Search is bounded to eight years.
 Public-holiday calendars and arbitrary RRULE syntax are not implemented.
 
-New tasks, including work deferred by a busy reply session, default to Codex
-`gpt-5.6-luna` with `max` reasoning independently of the creating chat.
-New chats use the separate Sol/medium preset. Busy reply `defer` accepts optional
-`model` and `effort` fields; retries preserve the first saved task choice.
-Use `--cli`, `--model`, and `--effort` to specify another choice. `xhigh` and
-`max` are available only with Codex `gpt-5.6-luna`; every other model remains capped at
-`high`. Non-Codex adapters inherit native effort when unset. Editing preserves the existing AI
-choice unless those flags override it. Stored choices are checked again at
-launch, including schedules saved before a policy change.
+New tasks inherit selected engine settings. Explicit `--cli`, `--model` and
+`--effort` override those choices; omitted values use native defaults. Edits
+preserve existing choices. Historical deferred tasks keep their source context
+available through `ezenciel-agents-schedule context`.
 
 ## Execution and authority
 
-The relay checks due work once per second. Each occurrence enters the durable
-run queue with a stable ID. Background work runs in a fresh native CLI session
-and `work/tasks/RUN_ID/`, with snapshots of the agent's SOUL, USER and TOOLS files.
-Instructions must include any needed context or source paths; full chat history
-is not copied. Task folders remain for inspection and artifact delivery.
+Due occurrences enter the durable queue with stable IDs and literal task text.
+Background runs use fresh native sessions in `work/tasks/RUN_ID/`. No identity
+files or role instructions are generated there. Existing workspace Markdown
+provides context; the engine chooses what to read. Codex uses `AGENTS.md` or `.git`
+as its native project-root marker, so a nested task sees the existing agent scope. Task folders remain for
+inspection and artifact delivery.
 
 One writer runs per task directory. Up to four background tasks can run alongside
-the main conversation. When a Codex owner message arrives while work is busy, a separate restricted session reads recent messages and run progress and answers through the normal outbox. It can queue requested work through the scheduler, but cannot run shell commands, access plugins, or edit the agent workspace. Only one reply session runs at a time and it releases its slot after a 60-second reply deadline; this deadline does not apply to writer jobs. Its context is a bounded snapshot, not a shared native transcript. Delivered parallel replies are included as historical context in the next normal conversation turn. Codex 0.153.4 and 0.154.0 are supported for this restricted adapter. Other versions fail closed pending tool-surface validation. A recurring schedule has at most one pending
-or active occurrence. Agents should delegate long work with `create --now`, return
-to chat, and inspect `runs` or task progress when asked. Native subagents can be
-used inside the worker. Sharing provider profiles does not make concurrent CRM,
-file or browser writes safe: the agent must coordinate those resources.
+the main conversation. Foreground inputs queue while a foreground turn runs;
+ez does not create another reply agent. The agent can delegate or schedule long
+work and return to chat. It decides when to send through the message CLI.
+A recurring schedule has at most one pending or active occurrence. Shared
+provider resources still need writer coordination.
 
 Production relay/host execution has no wall-clock timeout. The old
 `EZ_EXECUTOR_TIMEOUT_SECONDS` setting is ignored. Individual network/tool waits
@@ -64,13 +60,14 @@ are an executor capability, configured through instructions. Ez has no goal API,
 continuation loop or rule equating a process exit with goal achievement.
 
 Scheduled Codex CLI tasks use a dedicated native app-server session, tested with
-CLI 0.153.4. A leading `/goal` in the instruction text maps to the same native
-goal command used by the interactive CLI. Codex automatically starts subsequent
-turns; the transport stays connected until the native goal is complete or stops
-for attention. It sends no continuation prompts and stores no Ez goal state.
-Goals created by the agent's native tools also keep the session alive. Ordinary
-tasks finish after their turn. A blocked, paused or limited goal is not reported
-as successful. Native RPC requests have a response deadline; running tasks do not.
+CLI 0.153.4. Ez forwards the full task as ordinary input without interpreting
+`/goal` or constructing a native goal objective. The engine handles the request,
+context and native goal creation. Codex owns continuation; the transport stays
+connected while a native goal is active and verifies its terminal state. It sends
+no continuation prompts and stores no Ez goal state. Ordinary tasks finish when
+the engine completes its turn without an active goal. A blocked, paused or limited
+goal is not reported as successful. Native RPC requests have a response deadline;
+running tasks do not.
 Each scheduled task has its own Codex state under `control/cli/codex/tasks/RUN_ID`,
 with a snapshot of the agent's Codex configuration and the existing auth link.
 Foreground chat and background tasks do not initialize or migrate one shared
@@ -109,6 +106,15 @@ artifacts are retained. The agent sends through the normal Telegram outbox;
 `completed` means executor exit, while provider delivery is recorded separately.
 A timeout or ambiguous send must not cause blind replay of the whole task.
 
+## Failure-review stop
+
+A schedule using `--when unreviewed-failures` stops dispatching its current
+revision after one of its own runs fails. The failed receipt remains available
+through `runs`/`run`; no new retry queue or automatic repair task is created.
+The paired owner or authorized maintainer diagnoses it and explicitly edits the
+schedule to resume. Marking the failure reviewed or pause/resume alone does not
+clear the stop. Ordinary recurring tasks retain their existing failure behavior.
+
 ## QA
 
 `pnpm verify` covers recurrence/DST, restart deduplication, authority revocation,
@@ -136,16 +142,6 @@ exercise cancellation, downtime catch-up and an explicitly requested native goal
 that needs more than one turn. Synthetic provider evidence does not prove real
 Telegram delivery, and a sleep test does not prove native goal persistence.
 
-Busy-chat regression probe (real Codex, synthetic Telegram):
-
-```sh
-pnpm exec tsx scripts/smoke-busy-reply.ts --transport
-```
-
-The probe holds a writer on a shared workspace, asks an owner question through
-the relay and host transport, and requires the restricted reply to complete
-while the writer remains active. It sends no real Telegram messages.
-
 ## Optional failure review
 
 Create a normal recurring schedule with `--every-seconds 900 --when unreviewed-failures --text-file templates/failure-review.md`. The condition advances empty occurrences without launching an executor. It considers only failures belonging to the paired owner. No separate monitor or automatic retry is introduced.
@@ -153,3 +149,11 @@ Create a normal recurring schedule with `--every-seconds 900 --when unreviewed-f
 `failures [--all] [--limit N]` returns failedAt, reason, exit code, native session, captured error and runtime versions. Capture keeps at most 4 KiB of redacted stderr; historical failures are not backfilled. `run RUN_ID` reads an owned run. `review RUN_ID --failed-at ISO --status resolved|attention --diagnosis TEXT --recovery TEXT --outcome TEXT` records the investigation without rewriting execution history. A stale timestamp is rejected; a later failure needs a new review. Restricted reply, external and isolated-task callers cannot review failures. An attention review is handed off, not repeatedly relaunched; another new failure wakes the next review.
 
 The prompt controls diagnosis, authorized recovery and quiet notification behavior. Inspect prior effects and receipts before retrying anything. A failed review run itself remains visible as a new failure for the next occurrence.
+
+The Telegram Scheduled tasks menu lists enabled schedules that still have a pending
+occurrence or a queued/running occurrence. Finished one-time tasks, paused
+schedules and revisions stopped for review are hidden. Each entry shows the
+effective engine/model/effort, next occurrence in UTC (or queued/running state),
+and the first sentence of its saved invocation
+prompt, limited to 140 characters. This is a read-only view; history and full
+prompts remain available through the scheduling CLI.

package/docs/setup.md

@@ -52,26 +52,16 @@ owner request for standalone plugin development is a separate workflow.
 
 ## Defaults and host prerequisites
 
-New agents using `codex` or `codex-gui` start with `gpt-5.6-sol` and `medium`
-reasoning, including when initialized with `ezenciel-agents-setup init`. This
-Ez default takes precedence over discovered host client defaults. Saved agent
-selections permitted by the current policy are preserved; use the AI settings to choose another model or effort.
-Ez accepts `xhigh` and `max` only for `gpt-5.6-luna`; every other model rejects explicit
-reasoning above `high` at selection and execution, including old saved or queued choices.
-Unset Codex model/effort resolves to
-Luna/max at launch. This governs Ez-managed launches; it is not an account-wide
-limit on independently launched native clients or executor-created native subagents.
-Other adapters inherit their native effort when none is selected in Ez. That
-inherited configuration is not capped by Ez; explicit above-high Ez selections
-are rejected unless they are Codex Luna/xhigh or Luna/max. Conversation presets pin Sol/medium; the lower-level
-Codex fallback is Luna/max for work without an explicit choice.
-
-New scheduled and one-off background tasks default to Codex Luna/max independently
-of the creating chat. Use scheduler `--cli`, `--model`, and `--effort` flags for
-explicit overrides. Editing a schedule preserves its settings unless overridden.
-Restricted messaging tasks use Sol/medium while retaining their approved tool
-and context boundaries. Upgrades add Responsive chat to saved choices without
-replacing the selected/default preset. See [responsive channels](responsive-channels.md).
+New agents use the selected engine's native model and effort unless a choice is
+explicitly saved. Scheduling inherits the selected engine settings; `--cli`,
+`--model` and `--effort` provide explicit overrides. Edits preserve saved choices.
+The installed client's catalog supplies supported choices; ez imposes no model-specific
+reasoning cap. Optional compaction settings are passed only when explicitly configured.
+
+Restricted correspondence and busy replies retain their audited Codex adapter and
+isolated tool permissions. They honor explicit model/effort choices; unset values
+use that isolated client's native defaults. Unrestricted user configuration is
+not imported into restricted sessions. No workflow prompt is added to input.
 
 Use the existing owner's host account. Unless a layout was supplied, use
 `${XDG_DATA_HOME:-$HOME/.local/share}/ez/packages/<version>/` for extracted main
@@ -199,7 +189,7 @@ node /absolute/ezenciel_agents/bin/ezenciel-agents-tools.mjs init \
 This binds a private `ez` and preserves native command access. The default catalog
 is empty. Do not supply a plugin catalog during first-time main onboarding.
 Initialization
-adds discovery instructions to the mind's TOOLS.md. Verify `tools/bin/ez plugins
+adds discovery instructions to the mind's AGENTS.md. Verify `tools/bin/ez plugins
 available` before the first agent turn. Also execute the agent-bound
 `ezenciel-agents-message --help` through the selected CLI sandbox and verify
 its actual tool output, so absent launchers or blocked execution are detected

package/docs/standalone-cli.md

@@ -23,12 +23,12 @@ node /absolute/package/bin/ezenciel-agents-tools.mjs init --standalone \
 ```
 
 Init starts nothing, uses an empty catalog by default, preserves existing
-TOOLS.md notes and appends the registry's discovery instructions. A registry
+workspace notes and adds a managed registry locator to AGENTS.md. A registry
 cannot be replaced by rerunning init. Keep the package at its original path:
 the launcher imports it. Status reports `main: null` without a relay binding;
 automated software upgrades currently require a relay deployment.
 
-Have each executor read the workspace's TOOLS.md and the installed plugin skills.
+Use `ez tools list --details` for generated installed-plugin descriptions, help shortcuts and absolute skill paths. Read only the relevant skill.
 Add that instruction to its existing project instructions without replacing them.
 Use the absolute launcher, or prepend its bin directory to that session's PATH.
 Never overwrite another global `ez`; it may belong to a different installation.