# Run a shift

Goal: help the people on the floor get the day's work done. Release work, move tasks along, record what happened, and deal with quality, stops and stock as they come up, without ever acting on a guess.

## Before you change anything

- **Every change is previewed and confirmed** (SKILL.md rule 3). Call the tool with `dryRun: true`, tell the user what it will do and set off, and make the real call only after their OK. Batch related changes and confirm them together.
- **You act as the user.** You can do what they can do, and you see the tasks they see. When a tool is refused for a permission, say which permission and who usually has it. Don't look for another way round.
- **Facts come from people or the data, never from you.** Counts, measurements, stop reasons and dispositions are what someone tells you or what EightyOne records. If you don't have one, ask.

## Start of shift

1. `me_get`, then `guide_get` topic `company` for this company's own rules.
2. **What's waiting:**
   - `work_orders_list` for draft orders;
   - `tasks_list` for open and dispatched work;
   - `downtime_events_list` with `openOnly` for machines still stopped, and with `unclassifiedOnly` for stops nobody explained;
   - `inventory_reorder_suggestions` for what's running low.
3. Summarize it for the user before proposing anything.

## Release and dispatch

1. **Release:** `work_orders_release`. Its preview lists each operation, its machine, and which steps wait for a gate.
   - A step whose work center has several machines gets none. Ask which machine, then set it with `tasks_update` (`ssuId`).
2. **Dispatch:** `tasks_update` with `assigneeIds` and `status: "dispatched"`. People come from `personnel` ids (`me_get` shows your own).
3. **Linked work:** `tasks_create` with `after: { taskId, type: "dependency" }` creates a task that waits for another.

## Doing the work

- **During a run:** `tasks_record_counts` adds good and scrap counts. They add up, so record each new count once.
- **Completing a task:** start with `tasks_get_form` to list the fields. Then `tasks_submit_form` with the answers and `status: "done"`:
  - required fields must be filled;
  - a producing task also needs its counts (or counts recorded during the run);
  - a maintenance task needs failure codes: `problemCodeId`, `causeCodeId`, `remedyCodeId`.
- **What the preview tells you:**
  - a measurement outside its limits opens an NCR;
  - a machine-status field changes the machine's status;
  - the work order moves on.
- **Fields you can't fill:** photos, signatures, scans, stock and location fields are filled in the app. When one is required, the task waits for a person: tell the user who and what.
- **Partial work:** `tasks_submit_form` with `status: "incomplete"`, an `incompleteReason`, and `createFollowUp: true` creates a follow-up for the rest.

## Quality

- **A failed check** opens an NCR by itself. `ncrs_open` is for problems people find: give `foundOn` (the task where it was found) and the lot or product.
- **Disposition:** `ncrs_disposition`, once per NCR, and only with the decision of someone who holds 'Disposition NCRs'.
  - Scrap moves stock to the bads bin and blocks the lot.
  - Rework creates a rework task.
  - A blocked lot can't ship.

## Stops

- **Reporting:** `downtime_events_open` for a machine without telemetry; `downtime_events_close` when it runs again.
- **Classifying:** `downtime_events_classify`, only with the reason the operator gives. An unexplained stop is a gap to report, not a guess to fill.
- **Maintenance:** a technician's meter reading goes in with `meters_record_reading`. Its preview says whether it opens a maintenance task.

## Stock

- **Receiving:** `purchase_orders_receive`, per line, into the unit the user names, with the lot for lot-tracked products.
- **Moving:** `stock_transfer`, never more than `storage_units_get` shows is there.
- **Shipping:** `shipments_create` (a draft holds no stock), then `shipments_ship`.
- **Cycle count:**
  1. `inventory_counts_create`;
  2. counts from the count task in the app, or `inventory_counts_record_lines` from what someone reports;
  3. `inventory_counts_finalize`;
  4. show each difference, and get a decision for each one;
  5. `inventory_counts_reconcile`. Write-offs need an adjustment reason. Recount a line that moved during the count rather than adjusting it.

## Partners

- **Handing work over:** `handoffs_send` gives a task to a partner company.
- **Work sent to you:** `handoffs_decline` turns it down, with a reason the partner sees.
- **Goods from a partner:** `partner_deliveries_receive` books them.
- **Withdrawing** a handoff is done in the dashboard.

## End of shift

Summarize:
- what was released, completed and left open, and why;
- counts;
- NCRs opened and their dispositions;
- stops: hours, reasons, and which are still unclassified;
- stock changes;
- anything waiting for a person: a signature, a photo, a decision.