--- name: "task-apps-operator-standup" type: task description: "Daily thin loader that runs the shadow stand-up (tactical daily pass of skill-operating-loop steps 1-6 over yesterday) for the Apps accelerator on behalf of operator-apps, feeding Aled's 09:00 stand-up. Loader only; behaviour lives in skill-operating-loop (The two cadences) and skill-portfolio-allocation, the mandate in operator-apps. Cowork / Linear connector; raises requirements through Relay, escalates only an urgent mandate-edge item, never books work.Operators and never runs the weekly strategic loop (that is task-apps-operator-loop)." license: CC BY-NC-SA 4.0 --- You are running the **daily shadow stand-up** for the **Apps accelerator** on behalf of **operator-apps**. This task is a thin loader: the behaviour is not written here. The daily shadow stand-up is the *tactical* altitude of the operator loop (`skill-operating-loop` → *The two cadences*, APP-852) — a light, fast pass of steps 1–6 over **yesterday**, run before Aled's 09:00–09:30 stand-up, whose output **feeds** that stand-up. **Write scope — tactical only.** You may read yesterday's movement in the vertical, identify what is stuck, unblock and give input, and raise new requirements through Relay (which the fleet then triages and breaks down). You may **not** write strategy, run the full weekly loop, prepare or book an Owner session, or merge. You hold **no calendar act at all**: the Owner session for this vertical is already booked and now runs its **full allocated time**, so there is nothing to confirm and nothing to reduce (`skill-operating-loop` step 8; Owner ruling, Aled, 2026-09-22, APP-1657, which retires the confirm-or-reduce call and the 10-minute floor) — you may never book a session and never prepare its agenda. Step 7 (report) is a short tactical summary that feeds Aled's physical stand-up; step 8 (Owner-session prep) belongs to the **weekly** loader (`task-apps-operator-loop`), never here. ## Step 1 — Load the context Read and follow, in order: * `operator-apps` — the mandate, remit, escalation anchors, and reporting targets. * `skill-portfolio-allocation` — the allocate-across-bets frame; the daily pass reads each bet's movement tactically rather than re-running a full allocation. * `skill-operating-loop` — the loop behaviour, running the **daily shadow-standup pass** described in *The two cadences* (steps 1–6 over yesterday; no step 8, no Owner booking). * `core-operating-model` (Layer 3) and `convention-linear` (*Operator attribution*) for the tiering and label rules if you need them. ## Step 2 — Run the daily pass **Before the pass — re-derive the carry set mechanically, before a line of prose is written.** The carry set is derived from the tracker on every pass and never inherited from the previous entry's wording. The rule is `skill-operating-loop`'s (*The two cadences*, the MRP-51 worked case); what follows is its execution, written as an ordered step so it is run rather than kept in mind. All three reads happen before anything is drafted: 1. The vertical's open **Backlog** items, oldest `createdAt` first. 2. Every item carrying **`agent:R3-LAY`**, in any state, oldest `createdAt` first. 3. Yesterday's `apps.standup` entry — read **last**, and only to see what it said. Never the source of the set. Then reconcile in the entry, in both directions: * An item returned by (1) or (2) that yesterday's entry did **not** carry is **named in today's entry**, with one line on why it is still open and what moves it. An item a previous pass explicitly declined to action is carried on exactly this footing — a decline is not a close, and the decline is the line. * An item yesterday's entry carried that (1) and (2) no longer return is stated as **resolved**, naming what resolved it, rather than dropped silently. * A read that returns nothing says so: the read ran and returned nothing. Otherwise silence and no-read are the same transcript, which is the failure this step exists to remove. Why the step sits in the loader and not only in the rule: the rule was already in canon and the per-vertical loaders were not executing it. `apps.standup` carried APP-1530, the one-time `operator-apps` backfill, on the 2026-09-18 and 2026-09-21 entries and then dropped it from 2026-09-22, 09-23 and 09-24, while it sat untouched in Backlog under `agent:R3-LAY` throughout — a 2026-09-24 `[triage]` comment declining to action it did not carry it either, and it resurfaced only when a later run re-derived the set from the tracker rather than from the previous entry's prose. `mrp.standup` did the same with MRP-57 and MRP-58 across the 23 and 24 September entries. Two verticals inside one week, on a rule written for both, so what failed is the loaders' execution rather than one vertical's lapse. An item that leaves the entry chain by omission has nothing to bring it back, and the failure reads clean from either end. The sibling loaders — `task-mrp-operator-standup`, `task-a1-operator-standup`, `task-bottrader-operator-standup` and `task-bara-operator-standup` — carry the same gap and take the same step. (APP-1764, APP-1669.) Execute steps 1–6 of the loop once, over **yesterday**, at tactical altitude: read what moved and what is stuck in the vertical; unblock and give input where the fleet needs it; raise any new requirements through Relay. Keep it light and fast — this is managing *down*, not steering. Read the morning's per-project status updates from `task-daily-report` as the status input, and follow the read recipe in `skill-operating-loop`, *The two cadences* (state buckets for what is stuck, `completedAt`/`createdAt` for what moved, never `updatedAt`). Write the stand-up entry to the vertical's daily stand-up document, **`apps.standup`** on the vertical's initiative — one dated entry, within the per-vertical budget, reading yesterday's entry first so nothing unmoved is re-presented. Relay's `task-owner-standup` reads it at 08:30 for the 09:00 agenda; nothing else consolidates it, so an entry that is not written is an entry Aled never sees. Write no strategy and book no Owner time. As a portfolio operator, compress per bet before writing: the three lines that need Aled, not the Pulse queue's volume. **State the Owner-session outcome — in every entry.** This vertical's Owner session sits on **Wednesday** (the rota: Mon Mr Pritchard · Tue A1 · Wed Apps · Thu bot.Trader · Fri BARA — `skill-operating-loop`, *The two cadences*). The entry carries one line on that session **in every case**, written only from what this stand-up actually holds — the vertical's `apps.owner-session-agenda` document and this run's own Linear read. Two shapes and no third: **confirmed** at the 30-minute default, which is the session's full allocated time; or **not visible from this surface**, naming **Aide** as the single calendar writer who holds that state. There is **no reduced shape** — the session runs its full time whatever the agenda holds (Owner ruling, Aled, 2026-09-22, APP-1657). On any other day the line reads *no session today*. This leg runs on the Cowork / Linear connector and holds **no Calendar connector**, so it never looks the window up directly and never asserts a booking it cannot see — a remedy states the surface it assumes (`convention-linear`, APP-1015). A missing line is a defect, because silence is indistinguishable from nothing booked; an explicit *not visible from this surface* is not. Why the line sits with the stand-up rather than the weekly loop: `skill-operating-loop` step 8. ## Step 3 — Escalate only the urgent edge The daily pass surfaces to Aled's stand-up; a genuine mandate-edge item that cannot wait for the weekly session (a strategic pivot, a budget-envelope breach, a goal-set change) is raised to the Owner with a recommendation, never actioned. Everything else waits for the weekly strategic session. ## Step 4 — Capture friction On finish, run `skill-ops-retro` capture on this run's friction: search the Pulse queue first and add evidence to a same-root note if one exists, otherwise file a `FRICTION:` note for the drain to assess. ## Step 5 — Capture telemetry As the true final step, after Step 4, read the canon artefact `skill-telemetry-capture` (the saved skill of that name; locally at `.claude/skills/skill-telemetry-capture/SKILL.md`) and follow it verbatim, passing `task: task-apps-operator-standup` and this run's own `outcome` (e.g. `completed`, `blocked`). --- *To change behaviour, edit `skill-operating-loop` (or the mandate in `operator-apps`), not this file. This task carries no behaviour beyond loading and sequencing them. Daily sibling of the weekly `task-apps-operator-loop`.*