@jc_stack/ez-agents 0.1.0-beta.13 → 0.1.0-beta.18

package/.dockerignore

@@ -23,3 +23,6 @@
 !scripts/release-check.mjs
 !scripts/stage-qa.mjs
 !default-plugins.json
+!scripts/trusted-beta.mjs
+!scripts/generate-publish-caller.mjs
+!scripts/smoke-busy-reply.ts

package/.env.example

@@ -24,3 +24,18 @@ EZ_EXECUTOR_CLI=agy
 # Optional: OpenRouter API key for OpenCode CLI (Nemotron 3.5 Lightning)
 # OPENROUTER_API_KEY=
 # OPENCODE_MODEL=openrouter/nvidia/nemotron-3.5-lightning
+
+# Interactive Codex CLI context limit; native compaction preserves the session.
+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.
+EZ_REPAIR_ENABLED=true
+
+# Optional PagerDuty incident paging for critical Stocks outages. Put the routing
+# key only in the private relay.env file when running Docker; place the other
+# settings in docker.env so Compose passes them to the relay.
+# PAGERDUTY_ROUTING_KEY=
+# EZ_PAGERDUTY_STOCKS_HEALTH_URL=http://10.97.0.1:3006/health/critical
+# EZ_PAGERDUTY_POLL_SECONDS=30
+# EZ_PAGERDUTY_FAILURE_THRESHOLD=3

package/AGENTS.md

@@ -66,14 +66,14 @@ This package will be published as an open-source, lightweight Telegram-to-CLI re
 - Main-conversation jobs queue sequentially in `RunStore`. Scheduled/background work uses separate task directories and native CLI sessions (up to four alongside chat). Never share a mutable task directory. Delegation decisions and goal persistence belong to the agent/executor; there is no automatic planner or canned chat ACK. Production executor runs have no wall-clock timeout; cancellation is explicit.
 
 ## 7. Fail-Closed Authority (Channel Access ≠ Execution)
-- Incoming messages from unapproved senders must **never** spawn the executor. First DM registers an unapproved pairing request, then stops.
-- Group messages or unknown DMs fail silently.
+- Incoming messages outside the approved owner binding must **never** spawn the executor. A first DM or group message records a pending request only. Explicitly approved owner groups grant owner access to all human members in that exact chat; bots and anonymous posts are ignored.
+- Unapproved group messages from other senders and unknown DMs fail silently. Approved group text uses the existing conversation grant and restricted task runner. Paired-owner group text is discovery routed to the owner's private chat; it grants no group reply authority.
 - Stopping work (`/stop`) must terminate the active worker PID immediately (`SIGTERM`, escalating to `SIGKILL` if unclosed after 3s).
 
 ## 8. Mandatory Adversarial & Negative Tests
 Every pull request modifying authority, execution, or routing must include negative tests:
 1. Unapproved Telegram ID $\rightarrow$ no process spawned.
-2. Group message $\rightarrow$ silent ignore.
+2. Non-owner group message $\rightarrow$ silent ignore; owner group discovery $\rightarrow$ private destination only.
 3. Executor environment check $\rightarrow$ asserts `TELEGRAM_BOT_TOKEN` is `undefined`.
 4. Corrupt JSON in store $\rightarrow$ handled gracefully without process crash.
 5. Injected path traversal in IDs $\rightarrow$ rejected.
@@ -89,5 +89,8 @@ worktree/branch/PR, starting from fetched origin/main. Do not switch or mix work
 another task's checkout. Stage only this task's changes. Keep its worktree through
 review and QA; independent review and green CI precede an authorized merge.
 Never treat task completion as permission to merge or publish.
+Own the complete engineering/release handoff in CONTRIBUTING.md. Once ready,
+proactively request only missing merge/release authority, then ship and verify;
+do not leave the maintainer to discover ready drafts or operate the release.
 
 - In channel-backend mode, the application owns native sessions and actions. Forward normalized inputs with stable run IDs, recover only by idempotent backend submission, and deliver replies through the existing outbox. Never launch a fallback CLI or pass relay credentials into an executor.

package/CHANGELOG.md

@@ -1,5 +1,54 @@
 # Changelog
 
+## 0.1.0-beta.18
+
+- Await complete relay cleanup after fatal Telegram polling errors and preserve the primary failure.
+- Refresh package-owned shared guidance in owner worker prompts, including resumed and scheduled work, while preserving personal workspace instructions and restricted worker boundaries.
+- Include the reviewed beta.17 fixes. Earlier immutable unpublished candidates and existing beta acceptance limits remain.
+
+## 0.1.0-beta.17
+
+- Capture executor stderr before asynchronous PID persistence so fast failures retain actionable, redacted diagnostic evidence for agent-owned recovery.
+- Wait for executor cleanup and final run-state writes when stopping the relay, so shutdown does not return while its state is still being written.
+- Include the reviewed beta.16 runtime and catalog corrections. Earlier unpublished candidates remain preserved; existing beta acceptance limits remain.
+
+## 0.1.0-beta.16
+
+- Correct stale plugin-publication claims and link the catalog to live npm/GitHub release records. Agents must verify available versions instead of treating a dated catalog snapshot as a blocker.
+- Include the reviewed beta.15 runtime unchanged. Preserve earlier unpublished candidates and existing beta acceptance limits.
+
+## 0.1.0-beta.15
+
+- Include current reviewed model defaults, reply/status fixes, shared Library services and CPU limits, and the corrected main-CI publisher validation.
+- Testing beta; previously documented live-provider and fresh-host acceptance limits remain.
+
+## 0.1.0-beta.14
+
+- Preserve agent-specific scheduled authentication and model catalogs; show native
+  Codex defaults in status, and support explicitly approved group ownership.
+- Keep owner chat responsive during shared work with restricted reply sessions.
+  Capture redacted failure evidence and support quiet, owner-scoped reviews.
+- Add opt-in shared Docker plugin workers and agent-owned repair instructions.
+- Add optional PagerDuty Stocks monitoring with restart-safe recovery. Activation
+  requires the companion Stocks critical-health endpoint and private routing-key
+  configuration; real trigger/resolve delivery is not yet verified.
+- Publish verified beta artifacts through the shared trusted-publisher workflow.
+
+- Add explicit host-owned shared-workspace access and serialize bindings to the
+  same resolved repository path while retaining isolated task transcripts.
+- Bound interactive Codex context through native compaction and expose
+  content-free launch, execution and delivery timings.
+- Support owner-approved Telegram text groups and ongoing incoming-only grants
+  through restricted task execution; retain exact conversation/account authority.
+- Preserve revocation recovery and uncertain-send receipts. Ongoing WhatsApp
+  grants require the companion WhatsApp beta.13 provider.
+- Fix graceful container shutdown, isolate CI package sources and await RPC
+  fixture cleanup. Make verified release handoff proactive and agent-owned.
+- Beta limits: no group media; live group-recipient and final fresh-host/reboot
+  acceptance remain pending. No new live-delivery or latency claims.
+- Default core and plugin automatic updates to the beta channel; preserve saved
+  stable-only and manual policies.
+
 ## 0.1.0-beta.13
 
 - Escalate cancelled plugin clients and report container cleanup failures.

package/CONTRIBUTING.md

@@ -13,8 +13,9 @@ repository. Public docs describe shipped behavior and explicit limitations.
    Packaging/runtime changes also need the Docker checks in docs/releasing.md.
 5. Open a PR explaining the problem, resulting behavior, verification and limits.
    Include a short sanitized reproduction. State which tests were not run.
-6. A maintainer reviews and merges after CI. Maintainers use PRs too. No CLA,
-   ticket requirement, custom commit format or additional approval committee.
+6. Obtain independent review and required CI, then complete the
+   maintainer-authorized merge. Maintainers use PRs too. No CLA, ticket
+   requirement, custom commit format or additional approval committee.
 
 You are responsible for understanding submitted code, including AI-generated
 code, and having the right to contribute it under this repository's license.
@@ -48,8 +49,8 @@ docs/plugin-contributions.md.
   Branch from an unmerged feature only when the dependency is intentional and
   documented; do not quietly include it in an unrelated PR.
 - Open a draft PR when the change is reviewable. Report its scope, exact commit,
-  validation and remaining QA. A completed coding task can remain a draft;
-  implementation completion does not authorize merge or npm publication.
+  validation and remaining QA. Continue through the release handoff below;
+  implementation completion alone does not authorize publication.
 - Before merge, obtain an independent human or agent review of the final diff.
   The implementer's self-check and passing CI are not independent review.
   Reviewers inspect correctness, architecture, state/permissions and negative
@@ -66,6 +67,31 @@ docs/plugin-contributions.md.
   the clean task worktree after valuable work is preserved; never force cleanup.
   Delete its branch only after confirming merge or authorized abandonment.
 
+## Agent-owned release handoff
+
+The agent owns the engineering work through shipping: implement, run proportional
+checks, obtain independent review, repair findings, verify the packed artifact,
+and prepare the release. Reuse valid final-commit evidence; repeat checks when
+changes or failures invalidate it. Do not leave a ready feature silently in draft
+or ask the maintainer to run commands, coordinate reviewers, or operate CI.
+
+The maintainer's request is authorization for the requested work and its normal
+implementation steps. Do not ask them to approve the same work again. Once the
+applicable gates pass, execute the requested merge/release and report the packages,
+versions, channel, verification and material limits. Batch related packages in
+dependency order. Prepare the reviewed commits, artifacts and checksums before
+shipping. A request to merge does not silently expand to publication or changing
+a private package's visibility; a request to release already authorizes release.
+If shipping was not requested, report readiness and the next step without treating
+every completed feature as permission to publish.
+
+Complete the authorized merge, publication and rollout using
+docs/releasing.md, then verify registry metadata, downloaded artifact and the
+installed runtime. Report the outcome. Escalate only a product decision, missing
+credential/2FA, failed gate that cannot be repaired in scope, or material scope
+change. Human attention belongs on product intent;
+the agent operates the technical workflow.
+
 Example, substituting a unique task name and an absolute external directory:
 
 ```sh
@@ -74,3 +100,7 @@ git worktree list
 git fetch origin
 git worktree add -b feat/task-name /absolute/worktrees/task-name origin/main
 ```
+
+Beta publishing workflow changes follow [trusted publishing](docs/trusted-publishing.md).
+Validate wrong source, repository, package, version and artifact inputs with
+negative tests. Never dispatch publication to test authentication.

package/README.md

@@ -111,6 +111,9 @@ services; the existing host CLI and login are shared through one generic
 transport, with separate agent workspaces and sessions. See
 [Docker setup, state and QA](docs/docker-runtime.md).
 
+For optional PagerDuty paging of a critical Stocks outage, see
+[PagerDuty critical-outage paging](docs/pagerduty.md).
+
 Telegram `/status` shows the running relay and host versions plus installed
 plugin versions. The agent's `ez status` adds verified plugin runtime states and
 upgrade job receipts. See [status and upgrades](docs/upgrades.md).

package/compose.yaml

@@ -8,15 +8,22 @@ services:
     restart: unless-stopped
     stop_grace_period: 30s
     cap_drop: [ALL]
-    cap_add: [CHOWN, DAC_OVERRIDE, FOWNER, SETUID, SETGID, SETPCAP]
+    # Init must forward shutdown to the privilege-dropped relay. The entrypoint
+    # still removes every capability from the relay and its executor children.
+    cap_add: [CHOWN, DAC_OVERRIDE, FOWNER, SETUID, SETGID, SETPCAP, KILL]
     environment:
+      EZ_REPAIR_ENABLED: ${EZ_REPAIR_ENABLED:-true}
       EZ_AGENT_PURPOSE_FILE: /run/agent-purpose.md
       EZ_EXECUTOR_TRANSPORT: ${EZ_EXECUTOR_TRANSPORT:-host}
       EZ_CHANNEL_BACKEND_URL: ${EZ_CHANNEL_BACKEND_URL:-}
       EZ_AGENT_WORKSPACE: ${EZ_AGENT_WORKSPACE:?Set this agent workspace}
       EZ_CONTROL_DIR: ${EZ_CONTROL_DIR:?Set this agent control directory}
       EZ_EXECUTOR_CLI: ${EZ_EXECUTOR_CLI:?Set the host installation CLI}
+      EZ_CODEX_AUTO_COMPACT_TOKENS: ${EZ_CODEX_AUTO_COMPACT_TOKENS:-64000}
       EZ_EXECUTOR_TIMEOUT_SECONDS: ${EZ_EXECUTOR_TIMEOUT_SECONDS:-300}
+      EZ_PAGERDUTY_STOCKS_HEALTH_URL: ${EZ_PAGERDUTY_STOCKS_HEALTH_URL:-}
+      EZ_PAGERDUTY_POLL_SECONDS: ${EZ_PAGERDUTY_POLL_SECONDS:-30}
+      EZ_PAGERDUTY_FAILURE_THRESHOLD: ${EZ_PAGERDUTY_FAILURE_THRESHOLD:-3}
     secrets: [relay_env]
     configs:
       - source: agent_purpose

package/docker/run.ts

@@ -21,7 +21,7 @@ try { privateEnv = parseEnv(readFileSync(3, 'utf8')) } catch (error) {
   if ((error as NodeJS.ErrnoException).code !== 'EINVAL' && (error as NodeJS.ErrnoException).code !== 'EBADF') throw error
 } finally { try { closeSync(3) } catch {} }
 for (const [key, value] of Object.entries(privateEnv)) {
-  if (value !== undefined && ['TELEGRAM_BOT_TOKEN', 'GEMINI_API_KEY', 'OPENAI_API_KEY', 'EZ_CHANNEL_BACKEND_TOKEN'].includes(key)) process.env[key] = value
+  if (value !== undefined && ['TELEGRAM_BOT_TOKEN', 'GEMINI_API_KEY', 'OPENAI_API_KEY', 'EZ_CHANNEL_BACKEND_TOKEN', 'PAGERDUTY_ROUTING_KEY'].includes(key)) process.env[key] = value
 }
 privateEnv = {}
 const [command = 'start', ...args] = process.argv.slice(2)

package/docs/architecture/ai-selection.md

@@ -35,3 +35,11 @@ model/effort settings (or `models` for the default model). Claude reads user and
 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.
+
+`/status` resolves the configured model and reasoning effort for the current
+client-default seed from the agent's isolated Codex profile when that metadata
+is available. If the profile has no explicit model, it uses Codex's native
+default-model catalog for display. It displays that snapshot only; setup and
+refresh do not save the fallback, so the seed remains a native client default
+for later conversations. Desktop Codex remains its own opaque client default
+rather than inheriting CLI configuration.

package/docs/architecture/authority-boundaries.md

@@ -17,7 +17,7 @@ owner does not edit JSON. The agent uses `list` and `revoke` when asked.
 After approval the relay starts a restricted task, including the initial outgoing
 message. Incoming-only tasks instead wait for new correspondence and never create
 an opening run. Their task records use version 2 so older task readers fail closed. Matching new correspondence resumes that task in a fresh native session.
-Other contacts remain blocked. Each task has at most 30 distinct text sends;
+Other contacts remain blocked. Finite tasks have at most 30 distinct text sends;
 there are no payments, attachments, extra recipients, plugin installation,
 settings changes, or access to owner memory. A contact can have one active or
 pending task at a time. Completed, revoked, expired, replaced-source, and changed-
@@ -30,6 +30,29 @@ that each sentence serves the booking or that a correspondent is truthful. A
 prompt injection can still derail a task or elicit its shared context. It cannot
 use the provided tools to read owner files or select another destination.
 
+## Ongoing conversation permissions
+
+Incoming-only proposals may use `--until-revoked` for an ongoing conversation.
+This is a provider-neutral version-3 grant using the same owner, account, source,
+conversation and disclosure checks. It has no total reply count or time expiry.
+A 30-send ceiling applies per incoming run to bound runaway output, not per grant.
+Receipts stay durable; current-run keys are namespaced to avoid collisions with
+later replies. The runner gets current-run receipts and rolling group-only notes
+(up to 16,000 characters), not the owner's private session or files. Providers
+receive the largest supported timestamp for the watch; the core still checks
+revocation before every operation. Older versions reject version-3 grants.
+
+The native Telegram source implements the existing provider protocol for exact
+group IDs. It records selected text messages and sender identity, and sends only
+to the bound group with durable uncertain/accepted receipts. Bot messages and
+anonymous-admin posts are excluded by intake. Unselected owner group text remains
+private discovery; other unselected group messages cannot launch work. Source
+registration enables discovery, never reply permission. Voice and attachments are
+not handled by this group adapter. WhatsApp continues using its existing adapter;
+group and ongoing watch support requires the companion provider update. Older
+adapters reject ongoing grants at proposal time. Pending watch removals retry
+after service outages; core revocation blocks sends immediately.
+
 ## Native execution and core tools
 
 V1 uses audited Codex CLI **0.153.4** for task work, regardless of the owner's

package/docs/architecture/telegram-intake.md

@@ -2,7 +2,7 @@
 
 One owner, one bot, one relay writer per control directory. No database, extra agent, or executor loop.
 
-1. Gate the sender and private chat before accepting work.
+1. Gate the sender and private chat before accepting work. Text from the paired owner in a group is recorded only for discovery and routed to the owner's private chat; other group senders are ignored. Group controls, anonymous administrators and group replies are unsupported.
 2. Atomically save the raw update and deduplicate its Telegram update ID in `EZ_CONTROL_DIR/inbox.json`.
 3. Collect a short burst before downloading/transcribing. Seal batch membership on disk, then normalize in receive order. Captions, album IDs and quoted context travel with the media.
 4. Create one durable run using the batch's stable ID. A restart between run creation and intake completion finds that same run; it does not create a second job.

package/docs/docker-runtime.md

@@ -61,6 +61,21 @@ Live smoke uses the same host CLI and requires an actual Telegram receipt.
 Restart preserves pairing and files. One kernel lock excludes relay/smoke
 writers; exit 73 means a writer is active. Do not delete its lock to bypass it.
 Health requires recent polling and host-transport heartbeats, not just a process.
+Fatal Telegram polling errors, including `409 Conflict`, stop intake and await
+worker cleanup plus in-flight task/outbox writes before exit. A conflict still
+requires the operator to stop the competing bot poller; the relay does not retry
+around that ownership error. Pending and uncertain deliveries keep their existing
+outbox/receipt semantics; executor stdout is not replayed as a reply.
+Signal and fatal-error paths share one shutdown; a secondary cleanup error is
+reported without replacing the original startup/polling failure.
+
+The separate `control-state.lock` serializes authority JSON updates across CLI
+processes. A forced kill or host crash can orphan this exclusive-create sentinel.
+It deliberately has no age/PID-based auto-reclamation: expiry cannot prove that a
+paused writer is dead, and host/container PIDs are not interchangeable. For an
+orphan, stop the relay and all CLI writers for this deployment, preserve its
+control state, then remove only the verified orphaned `control-state.lock` and
+restart the single relay. Never remove a lock while a writer might still be live.
 Model catalog metadata is exported from the selected host CLI without credentials.
 The AI menu stays within that CLI. No automatic executor fallback is performed.
 
@@ -116,3 +131,23 @@ memory and host skill discovery are disabled for relay jobs. A conversation
 that already received unrelated global context must be replaced with a fresh
 native conversation; disabling injection does not remove prior turn content.
 This prevents automatic context sharing, not adversarial access by the host user.
+
+## Chat latency
+
+Interactive Codex CLI turns resume the existing native session and use native
+auto-compaction at 64,000 tokens. Set `EZ_CODEX_AUTO_COMPACT_TOKENS` in the Compose
+environment to change the positive integer threshold (for example, 32000 for
+lightweight chat). The setting crosses the host transport as a numeric option;
+relay secrets are still excluded from CLI environments. Older oversized sessions
+can take an extra compaction turn. Ez does not reconstruct transcripts or own a
+separate memory/compaction engine. Other providers, Codex desktop, native scheduled
+sessions and delegated tasks retain their own context policies. Channel backends
+such as AIFit own inference and must configure their own context limits.
+
+Content-free `run timing` logs identify the run and phase: queue wait and launch
+startup, executor duration (including model and tool work), and successful outbox
+delivery processing plus time since run creation. Host transport startup includes
+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.

package/docs/host-service.md

@@ -78,3 +78,22 @@ are not certified by these instructions or the headless Docker tests.
 
 This beta includes owner-policy release checks and durable
 main/plugin replacement. See [upgrade setup, tools and recovery](upgrades.md). Earlier main upgrade/rollback VM QA passed; final-release fresh-host/reboot and live plugin upgrade acceptance remain pending.
+
+## Shared application workspace
+
+Codex tasks inherit the agent's `control/cli/codex/auth.json` binding. Its default
+is a link to the host user's existing login. An operator may provision a private
+agent credential there during migration; new task homes link to that binding,
+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
+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.

package/docs/pagerduty.md

@@ -0,0 +1,42 @@
+# PagerDuty critical-outage paging
+
+PagerDuty alerting is an optional core capability. It observes Stocks from the
+Ez runtime and sends Events API v2 trigger and resolve events; Stocks never
+receives the PagerDuty routing key.
+
+Create an Events API v2 integration in the PagerDuty service that should page
+you. Put only its routing key in the deployment's private `relay.env` file:
+
+```dotenv
+PAGERDUTY_ROUTING_KEY=<Events API v2 routing key>
+```
+
+Then add the tunnel-visible endpoint and monitor settings to the deployment's
+non-secret `docker.env` file:
+
+```dotenv
+EZ_PAGERDUTY_STOCKS_HEALTH_URL=http://10.97.0.1:3006/health/critical
+EZ_PAGERDUTY_POLL_SECONDS=30
+EZ_PAGERDUTY_FAILURE_THRESHOLD=3
+```
+
+The core checks the endpoint every 30 seconds by default. Three consecutive
+unhealthy checks trigger one incident with the stable deduplication key
+`ez:stocks:critical-health`; recovery resolves that same incident. A failed
+PagerDuty submission remains eligible for a later trigger. On startup, the first
+healthy check resolves any incident left by the previous process, including an
+uncertain trigger delivery. Failed resolves retry without treating healthy
+Stocks as an outage. No key or health
+response is written to agent workspaces, executor environments, or logs.
+
+`/health/critical` is intentionally narrower than Stocks `/health`: it pages
+only when the Stocks source worker is unavailable. Provider freshness and other
+research-quality degradation remain visible in normal Stocks health/status but
+do not page. The endpoint returns only a status and component summary and must
+be reachable from the core runtime over the private tunnel. Run core outside the
+Stocks VM if you want a VM outage to be page-worthy.
+
+After deployment, use PagerDuty's test/escalation tooling or temporarily point
+the monitor at an intentionally unreachable private test target, then restore
+the real target and confirm the PagerDuty incident resolves. This is an explicit
+operational test and may notify your escalation policy.

package/docs/plugin-catalog.md

@@ -1,14 +1,28 @@
 # Available plugins
 
-This is Ez's public catalog of released plugins, for business owners and agents
-discovering capabilities. Each entry links to the plugin's own repository,
-installation instructions and releases. Install only the plugins needed for the owner's requested work.
+This is Ez's public catalog of registered plugins, for business owners and agents
+discovering capabilities. Each entry identifies its public source repository,
+package identity and release readiness. Registration does not prove that a package
+has been published. Install only released plugins needed for the owner's requested work.
 
 | Plugin | Capability | Package | Release |
 |---|---|---|---|
-| [WhatsApp](https://github.com/jdorado/ez-whatsapp) | Link an existing WhatsApp account so the agent can use its messaging tools. Uses WhatsApp Web linked devices through Baileys; requires an account already on a phone. | `@jc_stack/ez-whatsapp` | [0.1.0-beta.12](https://github.com/jdorado/ez-whatsapp/releases/tag/v0.1.0-beta.12) — testing beta |
-| [Composio](https://github.com/jdorado/ez_composio) | Discover integrations and full native tool schemas, connect requested accounts and perform authorized actions through a private broker. Requires a Composio project key; individual apps may require OAuth consent. | `@jc_stack/ez-composio` | [0.1.0-beta.1](https://github.com/jdorado/ez_composio/releases/tag/v0.1.0-beta.1) — testing beta |
-| [GitHub](https://github.com/jdorado/ez_github) | Create repositories, commit and push through native Git/gh with a private per-agent profile. Requires GitHub browser consent and Ez 0.1.0-beta.13 or newer. | `@jc_stack/ez-github` | [0.1.0-beta.1](https://github.com/jdorado/ez_github/releases/tag/v0.1.0-beta.1) — testing beta |
+| [WhatsApp](https://github.com/jdorado/ez-whatsapp) | Link an existing WhatsApp account so the agent can use its messaging tools. Uses WhatsApp Web linked devices through Baileys; requires an account already on a phone. | `@jc_stack/ez-whatsapp` | [npm versions](https://www.npmjs.com/package/@jc_stack/ez-whatsapp?activeTab=versions) · [GitHub releases](https://github.com/jdorado/ez-whatsapp/releases) |
+| [Composio](https://github.com/jdorado/ez_composio) | Discover integrations and full native tool schemas, connect requested accounts and perform authorized actions through a private broker. Requires a Composio project key; individual apps may require OAuth consent. | `@jc_stack/ez-composio` | [npm versions](https://www.npmjs.com/package/@jc_stack/ez-composio?activeTab=versions) · [GitHub releases](https://github.com/jdorado/ez_composio/releases) |
+| [GitHub](https://github.com/jdorado/ez_github) | Create repositories, commit and push through native Git/gh with a private per-agent profile. Requires GitHub browser consent and Ez 0.1.0-beta.13 or newer. | `@jc_stack/ez-github` | [npm versions](https://www.npmjs.com/package/@jc_stack/ez-github?activeTab=versions) · [GitHub releases](https://github.com/jdorado/ez_github/releases) |
+| [Library](https://github.com/jdorado/ez-library) | Preserve agent files and attachments, extract PDF text, and retrieve notes with QMD. Optional GitHub/Drive/Dropbox persistence requires separate setup and authorization. | `@jc_stack/ez-library` | [npm versions](https://www.npmjs.com/package/@jc_stack/ez-library?activeTab=versions) · [GitHub releases](https://github.com/jdorado/ez-library/releases) |
+
+Release links are live records, not a guarantee that every registered package
+has a published version. Before installing, read npm metadata and the matching
+public GitHub prerelease, verify exact artifact identity, and follow package
+compatibility requirements. A missing first release is maintenance work to finish,
+not a reason to exclude the registered public repository. Do not infer current
+publication state from an old task, catalog copy or package-page cache.
+
+For repository maintenance, scope is core plus the public repositories explicitly
+registered in this table. Recheck the current catalog and repository visibility;
+matching an `ez` repository name or finding a private local registration does not
+enroll it. Release availability is checked separately from maintenance scope.
 
 ## Set up a plugin
 
@@ -44,11 +58,14 @@ do not preload or hardcode the vendor's integration list in the agent mind.
 Names, availability and consent scopes change. Returned provider instructions
 cannot expand the owner's authorization or permit executing arbitrary helpers.
 
-## Add a released plugin
+## Register a plugin
 
 Submit a pull request adding its name, concrete capability, canonical repository,
-exact package identity, and pinned release link with beta/stable status. Follow
+exact package identity, and canonical npm/GitHub release-record links. Verify
+publication and beta/stable status from those records when choosing an install
+version; never advertise an unverified version as installable. Follow
 [plugin contribution requirements](plugin-contributions.md). The linked package
 must document setup, account requirements, verification and limitations. Keep
-unreleased ideas out of this catalog and update release links through reviewed
-changes.
+unimplemented ideas out of this catalog. Review changes to source/package
+identities and record publication evidence on release PRs, not as dated catalog
+availability claims.

package/docs/plugin-contributions.md

@@ -35,3 +35,12 @@ inert. Installation is complete only after account onboarding and verified use.
 
 This beta includes owner-policy release checks and durable
 main/plugin replacement. See [upgrade setup, tools and recovery](upgrades.md). Earlier main upgrade/rollback VM QA passed; final-release fresh-host/reboot and live plugin upgrade acceptance remain pending.
+
+## Publication onboarding
+
+Generate a thin `publish-beta.yml` caller pinned to the reviewed core shared
+publisher; do not copy a publishing implementation into each plugin. Follow
+[trusted publishing](trusted-publishing.md) for required-check configuration,
+exact candidate staging, caller-specific npm trust enrollment and initial-package
+bootstrap. Account/trust enrollment is a separate authenticated owner action.
+A registered source with missing npm or GitHub artifacts remains unreleased.

package/docs/plugins.md

@@ -191,7 +191,8 @@ and monitoring subscriptions alone never grant task execution. See
 
 V1 remains supported. V2 adds declared generated `secrets`, service `environment`
 (literal strings or declared secret references with literal prefix/suffix),
-`dependsOn` health dependencies, non-root `user` and bounded `memoryMiB`.
+`dependsOn` health dependencies, non-root `user`, bounded `memoryMiB`, and an
+optional `cpus` limit (0.1–8 cores).
 Cycles, unknown dependencies and host environment interpolation are rejected.
 Secrets persist privately across reinstall and are never included in registry
 responses. Twenty provides a complete v2 backend example.
@@ -228,3 +229,13 @@ main/plugin replacement. See [upgrade setup, tools and recovery](upgrades.md). E
 Find released packages and the agent-owned registration path in the
 [plugin catalog](plugin-catalog.md). This listing does not change the empty
 default installation or connect provider accounts.
+
+## Optional shared worker (deployment schema 3)
+
+Schema 3 adds one optional `sharedServices` entry. It is never built or started by ordinary installation/start. `plugins shared-enable <plugin> <key>` creates or discovers it on the selected Docker daemon and recreates that plugin's clients with a read-only `/inference` socket volume. `shared-disable` removes only the client attachment; `shared-status` is read-only. Default per-agent files, networks and indexes remain unchanged.
+
+A shared entry declares `identity` (stable host resource ID), `buildTarget`, `memoryMiB`, optional `cpus` (default 0.5 CPU core; range 0.1–8), `healthcheck` (literal argv), `clients` (declared service names), `clientEnvironment` (literal environment entries), and `files` (packaged worker implementation/dependency paths). The manager fingerprints those files and the specification. Compatible package changes preserve attachments during managed updates; incompatible worker changes block an attached upgrade before stopping clients. The shared target must initialize `/inference` and `/models` for UID/GID 1000. Only its IPC volume is exposed to clients. The worker runs with dropped capabilities, bounded memory/PIDs and no published ports; outbound networking permits explicit model downloads. Library containers never receive Docker access.
+
+Docker's unique container name arbitrates concurrent first creation. Existing resources must match ownership and implementation labels. Labels assume a trusted Docker administrator; they are not credentials. Different Docker daemons are separate sharing domains. Stopping/uninstalling a plugin never stops or deletes the shared worker or model volume. Automatic shared-worker upgrades and garbage collection are not implemented; coordinate replacement explicitly after detaching all clients. Uninstall/reinstall resets client opt-in.
+
+Shared workers have a hard Docker CPU quota of half a core by default, across all attached agents combined. This leaves capacity even on a one-core host; it is not 50% of every core. The reviewed descriptor can set a different `cpus` value. Discovery refuses a worker whose actual CPU quota has drifted, rather than silently attaching to an unlimited process. Builds are not covered by the runtime quota.

package/docs/releasing.md

@@ -3,7 +3,9 @@
 Use the same checks for maintainer and external changes. Each repository versions
 independently with SemVer: patch for compatible fixes, minor for new capabilities;
 before 1.0, breaking CLI/state changes require a minor bump and migration notes.
-No automatic dependency updates, release bot or credentials in pull-request CI.
+No automatic dependency updates or credentials in pull-request CI. The agent
+operates this process under the authorization rules in CONTRIBUTING.md; a
+separate release bot is not required.
 
 1. In an isolated release worktree/PR, finalize package version and CHANGELOG.md;
    update plugin manifest version when present. After lockfile changes, copy
@@ -32,14 +34,20 @@ No automatic dependency updates, release bot or credentials in pull-request CI.
    fill package.json repository, homepage and bugs with the actual public URLs.
    Enable GitHub private vulnerability reporting; verify the route. Protect main
    with CI and independent PR review. Maintainers use the same process.
-7. Record independent review and green CI for the final release PR, then obtain
-   maintainer merge/release authorization for the exact commit, tarball SHA-256,
-   license/third-party obligations and known limits. Merge the release PR and
+7. Record independent review and green CI for the final release PR. The
+   maintainer's release request supplies authorization: do not ask for a second
+   approval. Record the prepared commit, tarball SHA-256, third-party obligations
+   and known limits. If release is outside the request, report readiness without
+   publishing. For an authorized release, merge the release PR and
    verify its tree matches the reviewed source before tagging `v<version>` and
    publishing that tarball:
-   `npm publish /absolute/candidate.tgz --access public --tag beta --registry https://registry.npmjs.org/`
-   for prereleases (use `--tag latest` only for an approved stable release).
-   Use interactive npm authentication with 2FA; never paste tokens into CI or docs.
+   `npm publish /absolute/candidate.tgz --access public --tag latest --registry https://registry.npmjs.org/`
+   for approved beta releases as well: `latest` is the default distribution tag,
+   not a claim that a SemVer prerelease is stable.
+   For unattended beta publication use the [shared trusted publisher](trusted-publishing.md)
+   and its exact-artifact staging/readback contract. Initial package publication
+   requires authenticated npm with 2FA before trust can be enrolled; never paste
+   tokens into CI or docs.
 8. Create the GitHub release from CHANGELOG.md, attach artifact/checksum, and
    install the registry version on a clean host. Verify metadata and the same
    onboarding path before posting launch copy. Stop rollout on failure; publish
@@ -53,13 +61,16 @@ credential revocation; do not delete volumes as a routine rollback.
 ## Beta channel
 
 Use SemVer prereleases (`0.1.0-beta.1`), GitHub's prerelease flag and npm's
-`--tag beta`; never mark a beta latest/stable. For this first beta the maintainer
+`--tag latest` so default installs and the package page advance automatically.
+The version and GitHub release remain prereleases; stable-only update policies
+still exclude them. The legacy npm beta tag is no longer advanced. For this first beta the maintainer
 explicitly deferred real account/reboot acceptance. Keep that limitation in the
 README and release notes. Source/tarball publication is permitted after the
 automated gates; deferred live checks remain required for stable release.
 GitHub repositories use `jdorado`; npm packages use `jc_stack`. Verify
 `npm whoami --registry https://registry.npmjs.org/` returns `jc_stack` before
-publishing. Never infer npm scope ownership from a GitHub login. After publishing,
+interactive publication. OIDC publication instead requires package-owner trust
+enrollment for the exact caller workflow; `whoami` is not its publication gate. Never infer npm scope ownership from a GitHub login. After publishing,
 read back `npm view @jc_stack/ez-agents@0.1.0-beta.12 name version dist-tags --json`
 (using the release being published), download it with `npm pack`, and verify its
 contents/checksum against the reviewed artifact. Keep the npm artifact and

package/docs/repair.md

@@ -0,0 +1,41 @@
+# 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.
+
+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.
+
+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.
+
+## 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
+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.