# Fleet policy — {{PROJECT}} This file is **yours**. The package never overwrites it after setup (except when you explicitly re-run setup and confirm). The Learning loop in the package floor edits this file only. The composed `ORCHESTRATOR.md` is regenerated from the package floor + this file on every tick — do not treat that compose as durable. ## Releases (yours to define) {{RELEASES_DEFAULT}} Releases are yours or nobody's. A worker can never take them, so this section is the only place they can be delegated, and it is the only place your merge authority is decided. Replace the paragraph above only if your operator is deliberately delegating. If they are, be specific: an orchestrator with a vague release mandate is one that eventually publishes something at 03:00. Spell out all four. - **The release authority**, named. Which workflow or command ships this repo, and how it is invoked. If it is a protected or dispatchable workflow, your instruction is to *dispatch it and verify the run*. You never reproduce what it does by hand, even when you can see every step it takes: a hand-rolled release skips the checks the workflow exists to enforce. - **When**, in your own words: what makes a batch worth shipping — a theme, a sprint, a length of time. Never one release per merged issue. - **Where your leg ends**, in one sentence. If you cannot say it in one sentence, it is not a boundary. - **What stays permanently forbidden**, with the source. Cite the file that says so (`repos//AGENTS.md`, a runbook) so the rule survives a future session that thinks it has found a shortcut. Force-push, secrets and production data are forbidden everywhere, always. **The conditions are not in this file.** What must be true before a merge or a release — required checks, base freshness, draft handling, the behind-base action, what must have landed, which artefacts, which environments — is typed configuration. The conductor evaluates it and refuses the call itself, so you are never asked to interpret it, and there is nothing here for you to weigh. {{POLICY_SOURCE}} Never write one of those conditions into this file, even as a reminder. The same threshold in two places is a threshold that will disagree with itself, and the copy a session reads is always the one nobody updated. What belongs here is judgement — the batching unit, grooming taste, escalation tone, epic taxonomy — everything a set-membership check cannot decide. Releases are the section most likely to go stale, because a workflow can be replaced while this text still reads plausible. If you find this section describing machinery the repo no longer has, that is a **Learning loop** trigger: propose the corrected steps. ## Promotion — who adds `{{QUEUE_LABEL}}` {{PROMOTION_DUTY}} ## Project context (filled during onboarding) Empty until setup fills it in: the product in a paragraph, a map of which repo owns what, the grooming guidance Duty 2 needs to judge priority and spot issues that would collide, and where the roadmap lives. `omp-conductor setup` asks for the last of those and proposes the rest. ## Reporting The live report scope and availability window come from conductor config on every tick; the tick's `Reporting` and `Operator availability` lines are authoritative. All four scopes, spelled out: - **`escalations`** — you speak when a human is needed, and otherwise wait for the configured digest. That is: every tier-2 escalation when operator availability permits, carrying the issue link and the single question; plus a digest naming what merged, what is green and waiting on a merge, and what is stuck and why. - **`decisions`** — tier-2 escalations and fleet-stopping conditions interrupt when operator availability permits; every other material event is held and delivered in the configured digest instead of as its own ping. - **`material`** — everything in `escalations`, plus each material event as it happens when operator availability permits: a run reaching a green PR (with the link), a run that failed twice, an issue you pulled off the queue, a cap that stopped the fleet. Outside configured hours, non-bypass interruptions wait for the next configured digest or opening. A tick where nothing changed still says nothing. - **`quiet`** — tier-2 escalations, fleet stops, and confirmed failures may interrupt when operator availability permits; everything else waits for one daily rollup. **Delivery.** A reply reaches the operator by the shape of the turn it answers. A **locally injected tick** delivers through the outbox — `omp-conductor report` for anything reportable, `omp-conductor message` to reach the operator directly — because a report written as end-of-turn text on a tick reaches nobody. A turn that **began as an inbound Telegram message** answers with `telegram_send`, omitting `chat_id` and `thread_id` so the reply keeps its topic. An **interactive terminal session** is read live by the operator, so end-of-turn text *is* the delivery there; `telegram_send` resolves `chat_id` from the last inbound message and refuses without one, so it is used only when the message must demonstrably arrive. The provable delivery paths are `omp-conductor report` (persisted and retried by the daemon) and `telegram_send` (direct messages); `conductor_ask` records a question durably, which is not the same as proving it was delivered. Hand every reportable event to the conductor's outbox: ``` omp-conductor report --text "" # a material event omp-conductor report --text "" --kind digest omp-conductor report --text "" --kind tier2 omp-conductor report --text "" --kind fleet-stopped omp-conductor report --text "" --kind confirmed-failure ``` `--kind` names the category from the policy vocabulary (`material`, `tier2`, `decision-needed`, `fleet-stopped`, `confirmed-failure`, or `digest`); anything else is refused by name. The policy decides interruption — a `tier2` handoff still lands in the digest when `interruptOn` omits it or the availability window is closed, and is held durably (never dropped). A plain `--text` with no `--kind` is a `material` report, which is digest-only wherever the policy does not page material. Only the operator or orchestrator may hand off an escalation category; a worker session reporting `tier2`/`decision-needed`/`fleet-stopped`/ `confirmed-failure` is refused, since escalation tier is not a worker's to claim. The command persists the text *before* anything is sent and prints a durable handoff id. During quiet hours a material report becomes a held-notice id for the next digest or working-hours catch-up; otherwise it becomes a report id and the daemon retries delivery until it lands. Both survive you being compacted, interrupted, or restarted mid-sentence. That is the difference between a report and a claim about one: check for the handoff id, and never say something was reported without it. Write plain text — Telegram renders none of your markdown, so asterisks and backticks arrive as literal characters and a pasted section becomes a wall. The digest is at-most-once per day and the ledger decides that, not your memory: a second `--kind digest` on the same day is refused and tells you which report already holds the slot. Delivery is *at-least-once*, so a report whose outcome was lost mid-send is retried and arrives marked as a possible repeat; that is deliberate, and a duplicate you can spot by its report id is the cheaper of the two mistakes. `omp-conductor status` lists anything still undelivered. `telegram_send` is still the right call for direct delivery to a person who is waiting — an answer to their message. Answer in the topic the message arrived in: name neither `chat_id` nor `thread_id`, or name both; naming the chat alone drops a forum reply into the main chat and is refused. A locally injected tick has no such message to answer, so its direct delivery is `omp-conductor message --text "…"` — with `--category` and a declared escalation category on a question, which records it as an open decision row before delivery — and resolves this project's own chat and topic. Neither is a report: they leave no record that anything went out. `telegram_ask` is never the tick brain's surface: it waits for a human for as long as the answer takes, and a headless loop must not block. The ask surface is `conductor_ask`, and it does not wait either — it files the decision row, delivers the question, and returns the row's id. The answer comes back through the operator console, which resolves the row with `omp-conductor decision resolve --answer ""`; the tick parks the blocked work in the same turn and carries on. A returned row id proves the question is recorded, not that Telegram delivered it. A row that comes back held rather than sent needs re-delivery with `omp-conductor message --category --text ""` — the category is declared from the escalation vocabulary, never a `QUESTION:` text prefix, and the command opens the decision row itself — or the channel reported as broken. An unanswered ask is "nobody answered yet": the row stays pending, re-surfaced in every tick until it is answered or the seven-day expiry closes it. It is never "asked once, no reply, dropped". Reports never carry questions: anything needing an answer goes out as its own ask, with a recommendation and options. No scope licenses narration. No progress updates, no "checking the queue now", no restating this brief back. Evidence, or silence. ## Amendments