Morning Plant Pulse skill

Morning Plant Pulse

Chain 3. data-consolidate → daily-production-report → publish.

The only scheduled chain, and the only one with no approval gate. Those two facts are the same fact: it reads, it produces a page, and it writes to no system of record. The dashboard it publishes lives in the user's own Claude artifact store, which is not a system of record either. That is precisely why it is safe to run unattended, and why no other chain in this build should ever be scheduled.

The page is rebuilt overnight so it exists before the morning meeting. A supervisor otherwise spends sixty to ninety minutes assembling it by hand out of the same four or five exports. The first run creates one dashboard per site; every later run updates that same dashboard, so nobody has to save over yesterday's page.

Quick start

→ Join last night's exports; flag mismatched keys by class
→ Compute output vs plan, OEE with its three components shown separately
→ Downtime ranked BOTH ways: by minutes and by frequency
→ Price the losses. Week-over-week movers come from the stored day records
→ Write the day record, keyed <site>_<YYYY-MM-DD>. Missing export? data_complete: false
→ Find the dashboard: stored URL, then exact title. Neither? Create it
→ Say "updated" ONLY when the publish returned a URL in this run
→ Can't publish? Page saved to pulse-output/ + "the dashboard was not updated"
→ Reply: ~150-word summary naming the page; full page in the reply only if nothing could be written
→ Export did not land? STILL RUN. Gap at the top, gap in the trend, never a zero
→ Ask nothing. There is nobody there at 4am
→ Idempotent: a re-run overwrites that day's record on the same dashboard

---

Inputs

First, find the plant setup: from the task's own folder (never cd into the plugin), run python3 -I <this skill's folder>/../../shared/scripts/plant_setup.py find, do its setup_page_first step, then read the profile at profile_path and any rate at rates_path, per ../../shared/replies.md.

Input	Source	Form
Planning, production and maintenance exports	The M365 export folder	CSV/XLSX
Standard cost, open work orders	The ERP (NetSuite or Infor M3)	Connector
Maintenance work orders in progress	CMMS	CMMS connector, else the maintenance export
Stored day records, for the trend and week-over-week	The dashboard's own pulse_days collection	ArtifactData query, per ../../shared/contracts/pulse-day-record.md
The dashboard's URL	The ## Dashboards line on the Open work page, then an exact-title lookup	Open work page, Artifact list
Source clocks, shift pattern, day boundary	## Plant context	Config

---

The three steps

First, run the compute engine. Steps 1 and 2 are done in code that ships with this skill, so every run computes the same numbers the same way:

python3 -I <this skill's folder>/scripts/pulse_compute.py --exports <export folder> \
  --out pulse-output [--day YYYY-MM-DD] [--profile <profile_path>] [--rates <rates_path>]

It applies the ladder, the eight classes and the integrity flags of data-consolidate, and the OEE, ranking, pricing and exception rules of daily-production-report, and writes figures.csv (the figures block, one row per number with its filter), pulse_model.json (everything the page shows, already computed) and day_records.json (one day record per covered day). Build the page from pulse_model.json and quote figures.csv. Never recompute, retype or round a number it holds. The judgment stays yours: the wording, which exceptions are significant, the reschedule move, the publish. What each key holds is reference/compute-engine.md. If the engine cannot run (no code execution) or exits non-zero, do steps 1 and 2 as written below and say which happened; never mix the two.

1. Join the exports through data-consolidate, on the records the plant already has, with mismatched keys flagged by class.

2. Compute the report through daily-production-report: output against plan, equipment losses ranked by minutes and by frequency, priced in dollars, and the exceptions that need a decision today. Week-over-week movers come from the stored day records, read at the start of step 3 before the page is built, never from a prior page. The pulse hands that history to step 6 of daily-production-report.

3. Publish the dashboard. Per ../../shared/live-dashboard.md, which names every tool call. In order:

1. Find the dashboard. The ## Dashboards line on the Open work page first; then Artifact list for the exact title ": Operations Command Center"; only when both find nothing does this run create it. A scheduled run starts with no memory of earlier runs, so it looks every time.
2. Build the day record for the production day, every field, per ../../shared/contracts/pulse-day-record.md, keyed <site>_<YYYY-MM-DD>. A missing export makes it data_complete: false with the gap named. Its metrics are null, never zero.
3. Existing dashboard: read it, query pulse_days, set the day record, compute the trend from the stored records in code, then publish to the same url. First run: back-fill (below), publish with capabilities: {db: {}} and the fixed title, batch the records against the new URL, write the URL to the ## Dashboards line on the Open work page, then open the dashboard so it is what the person sees.
4. Render the short Operations page, after the publish so it can link to the dashboard: python3 -I <this skill's folder>/scripts/render_short.py --out pulse-output [--full-page-url <url>]. It writes operations-short-<site>-<day>.html beside the figures and checks itself; on a failed check it writes nothing, and the reply says so. It is a separate page from the dashboard and never replaces it. Per reference/short-page.md.
5. Report it, as the last line of the run: "Updated Fairview: Operations Command Center, <url>. Private to you until you share it." Or the fallback: the page saved as pulse-output/operations-<site>-<day>.html (in the reply only when no file can be written), its placement line, and "The dashboard was not updated: [reason]."

Say "updated" only when the publish returned a URL in this run. Never "shared," never "scheduled," never "posted." The dashboard is private until the user shares it, and the pulse never shares it. A run that says "updated" without a URL from this run has told the meeting to trust a page nobody rebuilt.

Only the pulse publishes the Operations dashboard. daily-production-report run alone, and Chain 4, keep offering their page in the conversation. Two dashboards showing the same numbers is how a meeting ends up arguing about which one is right.

Back-fill on the first run only. When the exports cover several production days, the run that creates the dashboard writes a record for every day the planning, production and downtime exports fully cover, so the trend opens with history. A day they only partly cover is written data_complete: false, so it shows as a gap rather than as a bad day. Later runs write their own day.

What the page holds, panel by panel, is reference/operations-dashboard.md.

---

What "safe to run unattended" actually requires

Three properties. Each is a real constraint, not a nicety.

It asks nobody anything. There is no one at 4am to answer. Where an attended run would ask which date range or which of several exports to use, the unattended run takes the production-day range from the ## Plant context block and says which it used. With no Plant context at all, it uses the latest complete production day present in the exports, says so in the freshness banner, and lists no plant profile among the gaps. It never blocks on the missing profile, and never picks today's date, which has no data. A run that blocks on a question produces nothing, and nothing is worse than a partial report, because the gap is only discovered at the meeting. The publish step asks nothing either: where two artifacts carry the exact title, it uses the stored URL's, or the most recently updated, and names both.

Asking nobody does not mean deciding for them. Where plan and output spell a part differently, the unattended run neither drops the row nor joins it silently. It shows the variance labelled provisional, shows both spellings verbatim, and lists each normalization it relied on as proposed, awaiting approval, for whoever reads the page to accept or reject. Normalizations on the profile's ### Approved normalizations list are used as they stand; each overnight run rebuilds the dataset, so that list is what carries a yes from one night to the next. This is not a gate — nothing is applied and nothing is written — and the rule is ../../shared/approval-gates.md, When nobody is there to ask.

A list of data problems holds problems, and it is built by class number. Take the classified mismatches from step 1 and route each class before any row is numbered:

Class	Where it goes
1 orphan, 2 format drift, 3 leading zeros, 4 revision suffix, 5 case and whitespace, 8 duplicate key	The numbered Data problems table, and its count
7 date window	The coverage line in the freshness banner. Not a numbered row
6 genuine one-sided record	"Checked, nothing wrong", a separate block after the table. Never a row number, never in the count
6 with contradicted_by set	The numbered Data problems table, as one-sided, contradicted by the named record, and its count. Never "Checked, nothing wrong"

A record decides its class from its own type and dates, never from a part number someone recognises. A Class 6 record that appears in the table and in the recap has still been counted as a problem; it appears in the recap only. A duplicate key is counted by the rows that collide at the tab's grain, from the query (work order, shift and production day): if WO-88201 has three rows, and two of them (509 and 480 good, both 07:00) are the duplicate; the 95 on the 23:00 shift is its own shift. Say both numbers, and the figures block shows the filter. And a downtime record from breakdown-diagnosis with no safety_flagged is blocked: listed first under "Blocked — safety status unknown," held out of both rankings, the totals and the pricing. MES and historian rows are untouched. Both rules are ../daily-production-report/SKILL.md, steps 7 and 8. The day record carries the same split: data_problems_count is the table's count, and a blocked record is outside every downtime figure stored.

It is idempotent. A re-run for the same production day overwrites that day's record by key and updates the same dashboard, rather than adding a second record or creating a second page. Somebody will re-run it, after a late export lands or because the first run was mistrusted, and two reports for one day is worse than one because the meeting then argues about which is right.

It reports gaps rather than failing on them. If last night's export did not land, the run still completes and says so at the top. A missing export is a finding, not an exception. Silence, stale data and a crashed run all read the same way to a supervisor at 6am: nothing to look at. A publish that fails is a gap of the same kind: the run falls back and says so.

---

Approval gates

None, by design. This chain is read-only and writes to no system of record. That is the whole reason it can be scheduled.

Anything that would need a gate does not belong in this chain. The reschedule proposals it produces are drafted for the scheduler and never applied.

Publishing the dashboard is not a gate. It writes to the user's own artifact store, not to M365 or any system of record, and the page is private until the user shares it. The ## Dashboards line on the Open work page is written without a gate for the same reason; never say the page was saved unless saved returned ok in this run. The ## Plant context block is never touched by this chain: changing it takes two turns and an approval nobody is there to give.

---

Scheduling

The plugin does not schedule itself. It provides a run that is safe to execute unattended; the host provides the trigger. Read ../../shared/scheduling.md.

Never tell a user the report has been scheduled. Describing the run as overnight is accurate; claiming to have scheduled it is not.

Whether an unattended, scheduled session can publish is unverified. The run checks for the Artifact and ArtifactData tools every time and falls back when they are absent. It never claims a scheduled run published.

---

Output

The reply is a summary of about 150 words; the full page is on the dashboard or in a file. When the publish did not return a URL, save the full page as pulse-output/operations-<site>-<YYYY-MM-DD>.html and name that path. The summary is the one in ../../shared/replies.md (200 words at most), plus one line per day record: its key, data_complete, the gap if any, and whether it was stored. A request that picks or skips sections is not the whole report: those sections go in the reply in full. With no way to write a file and no publish, print the full page in the reply instead. A record handed to another skill is saved and summarised, never pasted as raw YAML; memory blocks are written where the plant's memory lives; and the name on an approval is asked, never taken from the account. All three per ../../shared/replies.md.

The Operations Command Center dashboard — ": Operations Command Center", one per site, created on the first run and updated in place after that, per ../../shared/live-dashboard.md and reference/operations-dashboard.md. Its header reads Updated [timestamp] · data as of [timestamp]. Two panels:

• Today: a safety-flagged diagnosis record first, then the freshness banner, never a footnote, then today's actions (issue, impact, next step, owner role, and whether it is a decision, an investigation or an observation, per step 4 of the report order in ../daily-production-report/SKILL.md), then output against plan, OEE with its three components shown separately, downtime ranked both ways, priced losses, exceptions with a traced reschedule move per significant exception, "Blocked — safety status unknown," the numbered data-problems table with its count, and "Checked, nothing wrong" outside that count.
• Trend: OEE and its three components, output against plan, and downtime minutes for the last 14 and 30 days, and the week-over-week movers, all from the stored day records. A day with no data is a gap, never a zero. With no history yet, the panel says so and week-over-week is skipped.

Plus the structured dataset behind it so the numbers can be checked — including the figures block, which matters most here because nobody is watching the run. Every count in the page, and every count in any list of data problems, is printed from a computation and listed with its filter, and the page quotes the block. Every trend point is in the block too, with the records it came from. A problem count that does not equal the problems listed under it is the defect to look for. Per ../../shared/computed-figures.md.

The day record(s) — per ../../shared/contracts/pulse-day-record.md, on every run, stored or not: one line each in the reply (key, data_complete, the gap, stored or computed, not stored), and the field and value table of ../../shared/replies.md on the page.

The short Operations page — a file, never pasted into the reply. Name its path and give its decisions, one line each, above the last line. With no code execution there is no short page; say so in one line.

The last line — the dashboard line with its URL; or, when the dashboard could not be published, the page in the conversation, its placement line ("save it over yesterday's"), and "The dashboard was not updated: [reason]." Read ../../shared/command-center.md.

---

Edge cases and failure modes

• Last night's export did not land — run anyway, and report the gap prominently. Never silently reuse yesterday's data. The day is stored data_complete: false, and the trend shows a gap, never a zero.
• Partial data, one line's export missing — report on what is there and name what is missing.
• A re-run for a day already reported — overwrite that day's record and update the same dashboard. Never a second record, never a second page.
• A late export lands after the run — a re-run for that day overwrites its data_complete: false record with the complete one.
• First run, no stored history — back-fill what the exports fully cover. With nothing to back-fill, the trend panel says there is no history yet and week-over-week is skipped rather than shown empty.
• The dashboard was renamed — the title lookup cannot find it, so a new one is created. Say so, per ../../shared/live-dashboard.md.
• The publish fails or the tools are absent — fall back: page in the conversation, placement line, "the dashboard was not updated." The run never stalls on it.
• Reason codes heavily "Other" — that coverage problem is a finding of its own, not something to smooth over.

---

Degradation

Not available	What happens
The export folder	Run connector-only and name every tab that could not be built. Never treat a missing tab as empty
The downtime cost-per-hour	Price scrap only, and say downtime is unpriced
Stored day records	Skip week-over-week; the trend panel says there is no history yet
The Artifact or ArtifactData tools, including on an unattended run	The page in the conversation, its placement line, and "the dashboard was not updated." The day record is still in the structured output, marked not stored. Never "updated," "scheduled" or "shared"
The Open work page can't be written, for the ## Dashboards line	Find the dashboard by exact title, report the URL, and say the link was not saved
A CMMS connector (Limble or any other)	See below

If Limble isn't included, or no CMMS connector is live — negligible for this chain. It is an overnight batch, so an export cadence is already the correct cadence: the maintenance rows simply arrive in the same scheduled drop as production and planning. The freshness banner must name maintenance as an export-sourced input so nobody assumes it is live.

---

Chain position

This is Chain 3 itself. Members: data-consolidate, daily-production-report, then this skill's own publish step.

Metric. OEE visibility and supervisor hours, both owned by daily-production-report. The scheduled delivery is what earns the supervisor hours: the report exists before anyone builds it by hand.

---

Reference files

File	Load when
reference/compute-engine.md	Before building the page: what pulse_model.json holds and how each part is labelled
reference/short-page.md	Step 3.4 — the short Operations page: what it holds, and how it differs from the dashboard
../data-consolidate/SKILL.md	Step 1 — the join and the eight mismatch classes, when the engine cannot run
../daily-production-report/SKILL.md	Step 2 — OEE, the rankings, the reschedule scope boundary
../../shared/live-dashboard.md	Step 3 — finding, creating and updating the dashboard, the tool calls, the fallback
../../shared/contracts/pulse-day-record.md	Step 3 — every field of the day record, and the gap rule
reference/operations-dashboard.md	Step 3 — the Today and Trend panels
../../shared/scheduling.md	Before claiming anything about the trigger
../../shared/command-center.md	The Operations page, and when "updated" may be said
../../shared/computed-figures.md	Before emitting — the figures block
../../shared/approval-gates.md	When a match rests on a normalization nobody has approved