DO NOT MERGE — merge train: 3257,3258,3259,3260,3267,3217,3219,3250,3253

.env.example

@@ -383,10 +383,13 @@ OPERATOR_QUEUE_CREATE_RATE_WINDOW=60          # rate-limit window (seconds)
 OPERATOR_QUEUE_FLEET_CREATE_RATE_LIMIT=300    # fleet-wide create rate / window
 OPERATOR_QUEUE_MAX_SCAN_PER_CYCLE=500         # max requests scanned per agent per 5s cycle
 OPERATOR_QUEUE_MAX_FILE_BYTES=2097152         # skip an operator-queue.json larger than this (bytes)
-OPERATOR_QUEUE_TITLE_MAX=300                  # title char cap (truncate-with-marker)
+OPERATOR_QUEUE_TITLE_MAX=300                  # title char cap (truncate-with-marker belt; agent titles are refused/held at OPERATOR_QUEUE_ASK_TITLE_MAX_CHARS first)
 OPERATOR_QUEUE_QUESTION_MAX=4000              # question char cap (truncate-with-marker)
 OPERATOR_QUEUE_CONTEXT_MAX_BYTES=8192         # context serialized-byte cap (marker over)
 OPERATOR_QUEUE_OPTIONS_MAX_BYTES=4096         # options serialized-byte cap (dropped-marker over)
+OPERATOR_QUEUE_MAX_OPTIONS=5                  # #3243: options per agent ask, (something else) not counted (refused/held over; floor 2)
+OPERATOR_QUEUE_OPTION_MAX_CHARS=60            # #3243: characters per option (refused/held over; floor 16)
+OPERATOR_QUEUE_ASK_TITLE_MAX_CHARS=120        # #3243: title of an agent-raised ask (refused/held over; floor 40)
 OPERATOR_QUEUE_PROPOSAL_MAX_BYTES=8192        # proposal serialized-byte cap (native asks; refused with 422 over)
 OPERATOR_QUEUE_ID_MAX=256                     # max agent-supplied id length
 OPERATOR_QUEUE_EXECUTION_ID_MAX=128           # max execution_id preserved in a context marker

AGENTS.md

@@ -1,6 +1,6 @@
 # Trinity — Guide for AI Agents
 
-Trinity is an autonomous agent orchestration platform: every agent runs in its own Docker container with scheduling, observability, credential injection, channel integrations (Slack/Telegram/WhatsApp), and a tamper-evident audit trail — self-hosted on infrastructure the operator controls. Agents are plain Claude Code (or Gemini CLI) projects; Trinity is where they run in production.
+Trinity is the operating system for the AI-native company — open source, self-hosted, that you own. Every agent runs in its own Docker container with scheduling, observability, credential injection, channel integrations (Slack/Telegram/WhatsApp), and a tamper-evident audit trail, on infrastructure the operator controls. Agents are plain Claude Code, Gemini CLI or OpenAI Codex projects; Trinity is where they run in production.
 
 > **Detailed documentation index: [docs/user-docs/README.md](docs/user-docs/README.md)** — guides, agent management, credentials, automation, operations, integrations, and the full API reference live there.
 

CLAUDE.md

@@ -55,7 +55,7 @@ Enterprise **feature designs, paid-module schema, and the open-core gating/monet
 
 ## Project Overview
 
-**Trinity** is an **autonomous agent orchestration and infrastructure platform** — sovereign infrastructure for deploying, orchestrating, and governing fleets of autonomous AI agents on your own hardware.
+**Trinity** is the **operating system for the AI-native company** — open source, self-hosted, that you own. It deploys, orchestrates, and governs fleets of AI agents on your own hardware, and it is model-agnostic: each agent runs on Claude Code, Gemini CLI or OpenAI Codex.
 
 Each agent runs as an isolated Docker container with standardized interfaces for credentials, tools, and MCP server integrations.
 
@@ -332,7 +332,7 @@ curl -X POST http://localhost:8000/api/agents \
 
 | Repository | Description |
 |------------|-------------|
-| [abilityai/trinity](https://github.com/abilityai/trinity) | This repository - Autonomous Agent Orchestration Platform |
+| [abilityai/trinity](https://github.com/abilityai/trinity) | This repository - the operating system for the AI-native company |
 | [abilityai/trinity-ops-public](https://github.com/abilityai/trinity-ops-public) | **Claude Code ops agent** — manage any Trinity instance (health, updates, logs, rollback, provisioning) |
 | [abilityai/abilities](https://github.com/abilityai/abilities) | **Canonical agent development toolkit** — plugins for the full autonomous agent lifecycle (scaffolding, onboarding, deployment, scheduling, ops) |
 

README.md

@@ -1,6 +1,6 @@
 <p align="center">
   <a href="https://www.ability.ai/trinity">
-    <img src="docs/assets/trinity-hero.webp" alt="Trinity — The Sovereign AI Agents Platform" width="720" />
+    <img src="docs/assets/trinity-hero.webp" alt="Trinity — the operating system for the AI-native company" width="720" />
   </a>
 </p>
 
@@ -53,9 +53,9 @@
 
 ---
 
-## The Sovereign AI Agents Platform
+## The operating system for the AI-native company
 
-Trinity is a sovereign AI agents platform — build and run proprietary systems, from fully (or semi-) autonomous businesses to self-improving cognitive systems, all governed, auditable, and on infrastructure you control.
+**Trinity: the operating system for the AI-native company — open source, self-hosted, that you own.** Compounding intelligence your company owns. Every agent is governed and auditable, and runs on infrastructure you control.
 
 > **Claude Code writes the agent. Trinity runs it in production.**
 
@@ -72,7 +72,7 @@ Each agent runs in its own isolated Docker container with real-time observabilit
 
 **The problem:** Everyone wants autonomous AI agents. But your options are terrible — SaaS platforms where data leaves your security perimeter, custom builds that take 6-12 months, or frameworks that don't handle governance and audit trails.
 
-**The solution:** Trinity is autonomous agent orchestration infrastructure. Each agent runs in its own isolated Docker container. You get real-time observability, fleet-wide health monitoring, cron-based scheduling, agent-to-agent delegation, and cost tracking — all on your own hardware.
+**The solution:** Trinity is the operating system for the AI-native company. Each agent runs in its own isolated Docker container. You get real-time observability, fleet-wide health monitoring, cron-based scheduling, agent-to-agent delegation, and cost tracking — all on your own hardware.
 
 | Option | Problem | Trinity |
 |--------|---------|---------|
@@ -820,7 +820,7 @@ git push origin cli-v1.0.0
 
 This project is licensed under the [Apache License 2.0](LICENSE) — free for any use, commercial included, with an explicit patent grant. Run it on your own infrastructure or any cloud you control.
 
-Optional **enterprise modules** (SSO, user management, SIEM export, and more) are available under a separate commercial license. Contact [hello@ability.ai](mailto:hello@ability.ai) for enterprise licensing.
+Optional **enterprise modules** (user management, SIEM export, and more) are available under a separate commercial license. Contact [hello@ability.ai](mailto:hello@ability.ai) for enterprise licensing.
 
 ## Contributing
 
@@ -839,5 +839,5 @@ See [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines.
 ---
 
 <div align="center">
-  <sub>Built by <a href="https://ability.ai">Ability.ai</a> — Sovereign AI infrastructure for the autonomous enterprise</sub>
+  <sub>Built by <a href="https://ability.ai">Ability.ai</a> — the lab for AI-native companies</sub>
 </div>

config/agent-templates/trinity-system/CLAUDE.md

@@ -1,6 +1,6 @@
 # Trinity System Agent - Platform Operations
 
-You are the **Trinity System Agent**, the platform operations manager for the Trinity autonomous agent platform.
+You are the **Trinity System Agent**, the platform operations manager for this Trinity instance.
 
 ## Your Role: Operations, Not Orchestration
 

config/trinity-meta-prompt/prompt.md

@@ -1,6 +1,6 @@
 # Trinity Agent System Prompt
 
-You are a Trinity agent - an autonomous AI system capable of independent reasoning and execution.
+This agent runs on Trinity, the operating system for AI-native companies.
 
 ## Core Principles
 
@@ -45,10 +45,12 @@ Before performing an action that cannot be undone or verified afterwards — pay
 
 `ask_operator` takes a `request_id` and a `title`, plus optional `question`, `type`, `options`, `priority`, `context`, `proposal`, `to` and `expires_at`; its description has the details and the named refusals.
 
+**Write atomic asks.** One decision per ask; a title a person reads at a glance (by default at most 120 characters); options that name the choice only (by default at most 5 options, each at most 60 characters — the person can always answer `(something else)`), with the reasoning in `question` and what an option does in `proposal`; `context` as a few labelled facts for a person. The `ask_operator` description has the full rules.
+
 **Request IDs must be globally unique.** Derive the `request_id` from your current execution ID (see the Execution Context block), e.g. `approval-{execution_id}-{short-slug}`. Never use date-serial IDs like `req-20260307-001` — a second task that picks the same ID gets the first ask's receipt instead of a new ask. Re-using your own derived ID when the same task runs again is safe and intentional: it prevents duplicate requests.
 
 **Request types:**
-- `approval` — You need a yes/no or multi-choice decision. Provide `options`, and state the exact action and its parameters in `proposal` so the operator can verify what they are approving.
+- `approval` — You need a yes/no or multi-choice decision. Provide `options`, and state the exact action and its parameters in `proposal` so the operator can verify what they are approving. Never list `(something else)` as an option: the platform offers it on every approval. An answer of `(something else)` means none of your options is approved — carry out none of them; the person's instruction is in `response_text`, so re-plan from it or ask again.
 - `question` — You need freeform guidance. No `options` needed.
 - `alert` — You're reporting a situation. No decision needed; it goes to the operators.
 
@@ -80,7 +82,7 @@ Until it is removed, an entry appended to the `requests` array of `~/.trinity/op
 }
 ```
 
-The operator's answer is written back into the entry: `status: "responded"` with `response`, `response_text` and `responded_at` — never who answered. An item that has waited past the operator's aging bound carries a `platform.aging_since` timestamp written by Trinity — read it, never write to `platform`. While Trinity is holding new entries from this file, the file carries a `platform.ingestion` block: `reason` is `queue_full` (you already have `max_pending` open requests — wait for one to end), `rate_limited` (too many too fast — they are read again shortly) or `invalid_id` (an entry's `id` is malformed and will never be read — fix it), and `since` says when the hold began. Held entries stay `pending` and are read again every few seconds; the block is removed once nothing is held. `ask_operator` refuses the same cases immediately, with the reason. After processing a response, update the item's status to `"acknowledged"`. Keep only `pending` and `responded` items plus up to 3 recent `acknowledged` items. The platform database is the permanent record. An ID you raised with `ask_operator` is never read from the file.
+The operator's answer is written back into the entry: `status: "responded"` with `response`, `response_text` and `responded_at` — never who answered. On an approval, `response` is one of your options or the reserved value `(something else)`, which comes with the person's instruction in `response_text`. An item that has waited past the operator's aging bound carries a `platform.aging_since` timestamp written by Trinity — read it, never write to `platform`. While Trinity is holding new entries from this file, the file carries a `platform.ingestion` block: `reason` is `queue_full` (you already have `max_pending` open requests — wait for one to end), `rate_limited` (too many too fast — they are read again shortly), `invalid_id` (an entry's `id` is malformed and will never be read — fix it), or `invalid_options` / `invalid_title` (an entry breaks the ask caps: more than 5 options, an option over 60 characters or that reads as `(something else)`, or a title over 120 characters — the entry ids are listed under those keys beside `reason`, whatever the reason; shorten or split them, and they will not be read until they fit), and `since` says when the hold began. Held entries stay `pending` and are read again every few seconds; the block is removed once nothing is held. `ask_operator` refuses the same cases immediately, with the reason. After processing a response, update the item's status to `"acknowledged"`. Keep only `pending` and `responded` items plus up to 3 recent `acknowledged` items. The platform database is the permanent record. An ID you raised with `ask_operator` is never read from the file.
 
 ### When to Use
 

docker-compose.hosted.yml

@@ -274,6 +274,9 @@ services:
       - OPERATOR_QUEUE_QUESTION_MAX=${OPERATOR_QUEUE_QUESTION_MAX:-4000}                       # question char cap (truncate)
       - OPERATOR_QUEUE_CONTEXT_MAX_BYTES=${OPERATOR_QUEUE_CONTEXT_MAX_BYTES:-8192}             # context byte cap (marker over)
       - OPERATOR_QUEUE_OPTIONS_MAX_BYTES=${OPERATOR_QUEUE_OPTIONS_MAX_BYTES:-4096}             # options byte cap (dropped over)
+      - OPERATOR_QUEUE_MAX_OPTIONS=${OPERATOR_QUEUE_MAX_OPTIONS:-5}             # #3243 options per agent ask
+      - OPERATOR_QUEUE_OPTION_MAX_CHARS=${OPERATOR_QUEUE_OPTION_MAX_CHARS:-60}   # #3243 chars per option
+      - OPERATOR_QUEUE_ASK_TITLE_MAX_CHARS=${OPERATOR_QUEUE_ASK_TITLE_MAX_CHARS:-120}  # #3243 agent ask title
       - OPERATOR_QUEUE_PROPOSAL_MAX_BYTES=${OPERATOR_QUEUE_PROPOSAL_MAX_BYTES:-8192}           # proposal byte cap (native asks; 422 over)
       - OPERATOR_QUEUE_ID_MAX=${OPERATOR_QUEUE_ID_MAX:-256}                                    # max agent-supplied id length
       - OPERATOR_QUEUE_EXECUTION_ID_MAX=${OPERATOR_QUEUE_EXECUTION_ID_MAX:-128}                # max execution_id kept in a marker

docker-compose.prod.yml

@@ -211,6 +211,9 @@ services:
       - OPERATOR_QUEUE_QUESTION_MAX=${OPERATOR_QUEUE_QUESTION_MAX:-4000}                       # question char cap (truncate)
       - OPERATOR_QUEUE_CONTEXT_MAX_BYTES=${OPERATOR_QUEUE_CONTEXT_MAX_BYTES:-8192}             # context byte cap (marker over)
       - OPERATOR_QUEUE_OPTIONS_MAX_BYTES=${OPERATOR_QUEUE_OPTIONS_MAX_BYTES:-4096}             # options byte cap (dropped over)
+      - OPERATOR_QUEUE_MAX_OPTIONS=${OPERATOR_QUEUE_MAX_OPTIONS:-5}             # #3243 options per agent ask
+      - OPERATOR_QUEUE_OPTION_MAX_CHARS=${OPERATOR_QUEUE_OPTION_MAX_CHARS:-60}   # #3243 chars per option
+      - OPERATOR_QUEUE_ASK_TITLE_MAX_CHARS=${OPERATOR_QUEUE_ASK_TITLE_MAX_CHARS:-120}  # #3243 agent ask title
       - OPERATOR_QUEUE_PROPOSAL_MAX_BYTES=${OPERATOR_QUEUE_PROPOSAL_MAX_BYTES:-8192}           # proposal byte cap (native asks; 422 over)
       - OPERATOR_QUEUE_ID_MAX=${OPERATOR_QUEUE_ID_MAX:-256}                                    # max agent-supplied id length
       - OPERATOR_QUEUE_EXECUTION_ID_MAX=${OPERATOR_QUEUE_EXECUTION_ID_MAX:-128}                # max execution_id kept in a marker

docker-compose.yml

@@ -153,6 +153,9 @@ services:
       - OPERATOR_QUEUE_QUESTION_MAX=${OPERATOR_QUEUE_QUESTION_MAX:-4000}                       # question char cap (truncate)
       - OPERATOR_QUEUE_CONTEXT_MAX_BYTES=${OPERATOR_QUEUE_CONTEXT_MAX_BYTES:-8192}             # context byte cap (marker over)
       - OPERATOR_QUEUE_OPTIONS_MAX_BYTES=${OPERATOR_QUEUE_OPTIONS_MAX_BYTES:-4096}             # options byte cap (dropped over)
+      - OPERATOR_QUEUE_MAX_OPTIONS=${OPERATOR_QUEUE_MAX_OPTIONS:-5}             # #3243 options per agent ask
+      - OPERATOR_QUEUE_OPTION_MAX_CHARS=${OPERATOR_QUEUE_OPTION_MAX_CHARS:-60}   # #3243 chars per option
+      - OPERATOR_QUEUE_ASK_TITLE_MAX_CHARS=${OPERATOR_QUEUE_ASK_TITLE_MAX_CHARS:-120}  # #3243 agent ask title
       - OPERATOR_QUEUE_PROPOSAL_MAX_BYTES=${OPERATOR_QUEUE_PROPOSAL_MAX_BYTES:-8192}           # proposal byte cap (native asks; 422 over)
       - OPERATOR_QUEUE_ID_MAX=${OPERATOR_QUEUE_ID_MAX:-256}                                    # max agent-supplied id length
       - OPERATOR_QUEUE_EXECUTION_ID_MAX=${OPERATOR_QUEUE_EXECUTION_ID_MAX:-128}                # max execution_id kept in a marker

docs/CLI.md

@@ -1,6 +1,6 @@
 # Trinity CLI
 
-Command-line interface for the Trinity Autonomous Agent Orchestration Platform.
+Command-line interface for Trinity, the operating system for the AI-native company.
 
 ## Installation
 

docs/TRINITY_COMPATIBLE_AGENT_GUIDE.md

@@ -2092,7 +2092,7 @@ All human/operator communication on Trinity is **asynchronous**, mediated by the
 
 1. **Park** the request (approval / question / alert) with `ask_operator`, or, as the fallback, by appending an entry to the queue file.
 2. **End the turn.** A turn must never wait, poll, or sleep for a human response — a human may answer in minutes or days, and a blocked turn burns its entire timeout budget while pinning platform capacity. Never assume a synchronous human answer is available mid-turn.
-3. **Process the outcome in a later turn.** `get_my_ask` returns how an ask ended (answered, cancelled or expired, with the answer when there is one), and the Execution Context block of the system prompt lists the agent's asks that ended in the last 24 hours. For a queue-file entry, check the file for `status: "responded"` items, act on them, then mark them `"acknowledged"`.
+3. **Process the outcome in a later turn.** `get_my_ask` returns how an ask ended (answered, cancelled or expired, with the answer when there is one), and the Execution Context block of the system prompt lists the agent's asks that ended in the last 24 hours. For a queue-file entry, check the file for `status: "responded"` items, act on them, then mark them `"acknowledged"`. On an approval the answer is one of the agent's own options or the platform-reserved value `(something else)` (#3242): none of the options is approved — carry out none of them — and the person's instruction is in `response_text`. Never list `(something else)` as an option yourself; `ask_operator` refuses it. Write atomic asks (#3243): one decision per ask, a one-glance title (at most 120 characters), and at most 5 short options that name the choice only — the full rules are in the `ask_operator` tool description, and a queue-file entry over the caps is held as `invalid_options` / `invalid_title`.
 
 **Ask before irreversible actions.** Before an action the platform cannot undo or verify — payments, emails/messages through the agent's own credentials, public posts, destructive deletions — park an `approval` and end the turn when uncertain. Put the exact action in the ask's `proposal`. This matters most under re-delivery: pull-mode coordination (#1081) re-runs a turn whose worker died, so a task you receive may have partially run before. Check your own records and your earlier asks before repeating an irreversible effect; do the reversible parts first and gate only the irreversible step.