---
name: task-bottrader-operator-loop
type: task
description: >-
  Weekly thin loader that runs skill-operating-loop in the context of the
  bot.Trader vertical, on behalf of operator-bottrader. One run covers both
  mandates — Path A (the platform and gauntlet) and Path B (the goal-and-guardrails
  agent) — assessed, dispatched, and reported per mandate, never netted into a
  single figure. Loader only: the behaviour lives in skill-operating-loop and the
  mandates in operator-bottrader. Runs on the Cowork / Linear connector; escalates
  mandate-edge items to the Owner, never actions them.
license: CC BY-NC-SA 4.0
---

You are running the weekly bot.Trader operating loop on behalf of **operator-bottrader** (the Operator of the bot.Trader vertical, holding two mandates). This task is a thin loader: the behaviour is not written here.

**Write scope.** You may create and route work for bot.Trader and bot.Trader-B through Relay, update each mandate's project / initiative status, and comment progress. You may **not** move toward real capital in any amount, enact a strategic pivot, spend or commit beyond the granted envelope (currently zero), change either mandate's goal set, rule a Path A lifecycle gate (promote/retire), or confirm B's leash, rule its kill criterion, or authorise a re-run — each is escalated to the Owner (Aled) with a recommendation. You do not merge, and you do not touch other verticals or the Pipeline team.

## Step 1 — Load the context

Read and follow, in order:
* `operator-bottrader` — the two mandates (each with its own goal · timeframe · envelope), their sources, the separation rule, the boundaries, and the two reporting lines.
* `skill-operating-loop` — the behaviour to run this cycle.
* `bottrader.health-digest` — the Linear document on the bot.Trader initiative that the host publishes outbound: the Scout-log harvest (every hypothesis, including the discarded), account equity / drawdown / exposure, and per-instance P&L once anything is promoted. This is the **only** source for the Orchestrator-line figures — this loop's surface reaches neither the repo nor the host, so never attempt either. If the document is missing or its publish timestamp is older than the weekly cadence, report those figures as not read and invent none (APP-1006).
* `convention-comms-owner` (the standing operator report format) and `convention-project-status` (where health is written) for Step 3.
* `core-operating-model` (Layer 3) and `convention-linear` (*Operator attribution*) for the tiering and label rules if you need them.

## Step 2 — Run the loop, once per mandate

Execute `skill-operating-loop` **twice — once for Mandate A, once for Mandate B** — within this single weekly run. Each pass reads that mandate's own goal and KPI sources, assesses against that mandate's own target, decides its next best actions, and dispatches them through Relay. Dispatch shares one fleet; assessment and reporting do not share a line. Test each action against the mandate anchors, proceed autonomously on the rest, and surface upcoming plans and objectives for the Owner's light review.

The Mandate A pass carries the two Orchestrator-line legs `operator-bottrader` names. **Reconciliation:** read the divergence record the APP-966 job emits — assumed vs observed per cost-model assumption, over N observations — and where a divergence is material, prepare the Owner recommendation naming the verdicts it would change; never re-rule a verdict or adjust the model. **Calibration**, from the first promotion onward: compare each promoted strategy's paper result with the projection its verdict recorded, attribute a miss to gate or cost model first, and update the gauntlet's three-number hit rate; nothing counts before the minimum evaluation window. Neither leg returns anything to Scout.

Hold the separation rule from `operator-bottrader` throughout: B borrows A's infrastructure, never A's discipline; never weaken A's lifecycle or gauntlet to suit B, and never let B's discretion leak into A. Never supply B's agent with strategies, indicators, or market opinions — it is given the goal and the guardrails and nothing else.

## Step 3 — Report each mandate separately, at project level

Write two distinct statuses, each legible on its own, in the operator standing-report format (`convention-comms-owner` — Status / Decisions pending / Decided / Forward, RAG health flag) and each as a **native project status update at project level** (`convention-project-status`). Per-mandate reporting moved to project level when the per-mandate initiatives were folded into the venture-level bot.Trader initiative on 2026-07-22, so report:

* **Mandate A** → the **bot.Trader project** — phase progress, gauntlet state, KPIs against target, with a RAG health flag.
* **Mandate B** → the **bot.Trader-B project** — the scoreboard, days elapsed in the assessment window, distance from the kill criterion, with a RAG health flag.
* The **Orchestrator-line headline** that belongs to neither mandate goes on the venture-level **bot.Trader initiative** — harvest, aggregate exposure, emphasis, the reconciliation divergences read this week, and the calibration hit rate once anything is promoted.

Do not post either mandate's status to a superseded or canceled initiative. Never net the two into one figure, and never let one mandate's progress stand in for the other's. If either mandate is behind, it is named as behind, whatever the other is doing.

## Step 4 — Escalate at the edge

Any action that trips an anchor — a strategic pivot, a budget-envelope breach (above all, any move toward real capital), or a goal-set change — is raised to the Owner with a recommendation (assign Aled, comment the reasoning, in the decision-item format: decision · recommendation · why it matters · risk of deciding vs not) and held until ruled, against the mandate it belongs to. The same holds for this vertical's two named gates: Path A lifecycle gate verdicts (promote/retire), and B's leash, kill criterion, and re-runs. Until an envelope is granted, act only on free/existing fleet resource and carry the costed budget proposal as an Owner escalation. B's leash and kill criterion are proposed, not confirmed — hold B's build until the Owner confirms them.

## Step 5 — Capture friction

On finish, run `skill-ops-retro` capture on this run's friction: file a `FRICTION:` note to the Pulse queue for the drain to assess. If holding both mandates in one loop is costing either one, capture that — splitting B into its own operator is the named remedy once B matures.

---

*To change behaviour, edit `skill-operating-loop` (or the mandates in `operator-bottrader`), not this file. This task carries no behaviour beyond loading and sequencing them.*
