@umriss-ui/schedule 0.2.0 → 0.3.0

package/CHANGELOG.md

@@ -15,6 +15,73 @@ moves from here under the rule above.
 
 ---
 
+## 0.3.0 – Dependencies and blocked time (Sep. 2026)
+
+Needs `@umriss-ui/core` 0.11 and `@umriss-ui/charts` 0.8: it reads the renamed wording keys, the new ones for blocked time, and the charts' working-time functions; the peer ranges move to `^0.11.0` and `^0.8.0`.
+
+### Added
+
+- **Blocked time per lane.** `<BlockedTimes data={…} />` takes a list of
+  `BlockedTime` — `{ id, lane, from, to, label? }`, plain data keyed by lane
+  like a subtask — for leave, maintenance and any other time a lane is not
+  available. It is drawn hatched behind all the work on the lane, in forced
+  colours too, wherever the layer is declared.
+- **A finding: a subtask in blocked time.** `inBlockedTime(subtasks, blocked)`
+  returns every subtask that covers blocked time on its lane (lead-in and
+  lead-out included) as `InBlockedTime` — `{ subtask, blocked, lane, from, to }`.
+  `findings()` takes the blocked time as an optional third argument, and
+  `Findings` has the field `inBlockedTime`. The schedule marks the covered time
+  like an overlap; the tooltip and the keys' readout name it ("In blocked time
+  (Leave)"), and the plot's description counts it where there is any.
+  `ScheduleTooltipTarget` of kind `"subtask"` carries `blocked`, the blocked
+  times the subtask covers.
+- **Blocked time is part of where a subtask may go.** A drag — inside the plot
+  or from outside — does not put work into blocked time it did not already
+  cover: the ghost stays where it was allowed, the cursor says no, a line ties
+  the ghost to the pointer, and its label says "Blocked time" (`data-blocked`
+  on the ghost label). Alt with an arrow key steps over blocked time instead of
+  into it; Alt+Shift does not stretch into it. Work the data already put there
+  is never locked in.
+- A demo page, *Blocked time*.
+
+### Changed
+
+- **Neutral names for the schedule's terms** (ADR-0035). The schedule is for
+  any plan of work on lanes, and its names said "plant": a transport is now a
+  **dependency** with a **lag**, setup and teardown are **lead-in** and
+  **lead-out**, and a late transport is a **violated dependency** — with every
+  name built on them. One hard cut, no deprecated aliases. What the terms do is
+  unchanged: a dependency still joins two subtasks of one task, from an end to
+  a start, and its anchors decide whether it is violated. `]`/`[` and `t`/Shift+T
+  still walk along it. The tooltip, the ghost, the readout and the summary say
+  "Lead-in", "Lead-out", "Dependency" and "Violated dependency" (German
+  "Vorlauf", "Nachlauf", "Abhängigkeit", "Abhängigkeit verletzt").
+
+  | Before | Now |
+  |---|---|
+  | `Subtask.setup` | `Subtask.leadIn` |
+  | `Subtask.teardown` | `Subtask.leadOut` |
+  | `PlaceIntent.setup`, `.teardown` | `PlaceIntent.leadIn`, `.leadOut` |
+  | `PlacingItem.setup`, `.teardown` | `PlacingItem.leadIn`, `.leadOut` |
+  | `SetupIntent` (`kind: "setup"`, field `setup`) | `LeadInIntent` (`kind: "leadIn"`, field `leadIn`) |
+  | `TeardownIntent` (`kind: "teardown"`, field `teardown`) | `LeadOutIntent` (`kind: "leadOut"`, field `leadOut`) |
+  | `"setup"`, `"teardown"` in `intents` | `"leadIn"`, `"leadOut"` |
+  | `Transport` | `Dependency` |
+  | `Transport.duration` | `Dependency.lag` |
+  | `leaves: "teardown"` (the default) | `leaves: "leadOut"` |
+  | `arrives: "setup"` (the default) | `arrives: "leadIn"` |
+  | `TransportRoute`, `TransportAttachment`, `TransportEnds` | `DependencyRoute`, `DependencyAttachment`, `DependencyEnds` |
+  | `<Transports>`, `TransportsProps` | `<Dependencies>`, `DependenciesProps` |
+  | `LateTransport` (field `transport`) | `ViolatedDependency` (field `dependency`) |
+  | `lateTransports()` | `violatedDependencies()` |
+  | `Findings.lateTransports` | `Findings.violatedDependencies` |
+  | `ScheduleTooltipTarget`: `kind: "transport"`, `transport`, `late`; `lateTransports` | `kind: "dependency"`, `dependency`, `violated`; `violatedDependencies` |
+  | `ScheduleHit`: `kind: "transport"`, `transport`; `part: "setup" \| "teardown"` | `kind: "dependency"`, `dependency`; `part: "leadIn" \| "leadOut"` |
+  | ghost `data-findings` value `late-transport` | `violated-dependency` |
+  | grip `data-grip` values `setup`, `teardown` | `leadIn`, `leadOut` |
+
+---
+
 ## 0.2.0 – By keyboard and screen reader (Sep. 2026)
 
 Needs `@umriss-ui/core` 0.10 and `@umriss-ui/charts` 0.7: it reads the schedule's wording keys; the peer ranges move to `^0.10.0` and `^0.7.0`.

package/README.md

@@ -1,11 +1,12 @@
 # @umriss-ui/schedule
 
-The schedule of a plant: **subtasks** on **lanes** over time. One task runs
-across several machines in a fixed order, each stop has a main time with a
-setup before it and a teardown after it, and between the stops lie
-**transports** with durations of their own. The schedule draws all of it, marks
-what cannot work — two subtasks on one machine at once, a transport that cannot
-arrive in time — and lets a planner move things by hand without ever changing
+Work planned over time: **subtasks** on **lanes** — people, vehicles, rooms or
+machines. One task runs across several lanes in a fixed order, each stop has a
+main time with a lead-in before it and a lead-out after it, between the stops
+lie **dependencies** with lags of their own, and a lane can be **blocked** for
+leave or maintenance. The schedule draws all of it, marks what cannot work —
+two subtasks on one lane at once, a dependency whose lag does not fit, work in
+blocked time — and lets a planner move things by hand without ever changing
 the plan underneath them.
 
 ## Install
@@ -17,30 +18,30 @@ pnpm add @umriss-ui/schedule @umriss-ui/core @umriss-ui/charts
 Both `@umriss-ui/core` and `@umriss-ui/charts` are **peer dependencies**
 (ADR-0022): the schedule takes its styling regime, provider, formats and
 wording from core, and its time arithmetic — the affine scale, the time steps,
-the operating calendar, the canvas colour resolution — from charts. React 18 or
+the working calendar, the canvas colour resolution — from charts. React 18 or
 19 as a peer as well.
 
 ## The smallest schedule that runs
 
 ```tsx
-import { Lane, Schedule, Subtasks, Transports } from "@umriss-ui/schedule";
-import type { Subtask, Task, Transport } from "@umriss-ui/schedule";
+import { Lane, Schedule, Subtasks, Dependencies } from "@umriss-ui/schedule";
+import type { Subtask, Task, Dependency } from "@umriss-ui/schedule";
 
 const at = (h: number, m = 0) => new Date(2026, 2, 17, h, m).getTime();
 
 const tasks: Task[] = [{ id: "a-2041", color: "#2563eb" }];
 const subtasks: Subtask[] = [
-  { id: "cut", task: "a-2041", lane: "saw", from: at(6), to: at(7), teardown: 10 * 60_000 },
-  { id: "mill", task: "a-2041", lane: "mill", from: at(8), to: at(10), setup: 30 * 60_000 },
+  { id: "cut", task: "a-2041", lane: "saw", from: at(6), to: at(7), leadOut: 10 * 60_000 },
+  { id: "mill", task: "a-2041", lane: "mill", from: at(8), to: at(10), leadIn: 30 * 60_000 },
 ];
-const transports: Transport[] = [{ id: "move", from: "cut", to: "mill", duration: 15 * 60_000 }];
+const dependencies: Dependency[] = [{ id: "move", from: "cut", to: "mill", lag: 15 * 60_000 }];
 
 export function Plan() {
   return (
     <Schedule ariaLabel="Plan of Tuesday" initialDomain={[at(5), at(12)]}>
       <Lane id="saw" label="Saw" />
       <Lane id="mill" label="Mill" />
-      <Transports data={transports} />
+      <Dependencies data={dependencies} />
       <Subtasks data={subtasks} tasks={tasks} />
     </Schedule>
   );
@@ -51,7 +52,7 @@ export function Plan() {
 
 The schedule draws the data it is given and changes none of it (ADR-0023). A
 drag shows a **ghost** with the findings the drop would create, and ends in an
-**intent** — move, lane, stretch, setup, teardown — reported to the caller:
+**intent** — move, lane, stretch, lead-in, lead-out — reported to the caller:
 
 ```tsx
 <Schedule
@@ -65,12 +66,12 @@ drag shows a **ghost** with the findings the drop would create, and ends in an
 read-only. `canMoveTo(subtask, lane)` narrows it: a drag across a lane the
 subtask may not go to leaves the ghost where it was allowed and shows a
 refusal, and a refused drop reports nothing. A drag near the edge of the plot pans the plot along, and `snap`
-takes the tick raster, a step, or a step with an offset - shifts at 06:00,
+takes the tick raster, a step, or a step with an offset - handovers at 06:00,
 14:00 and 22:00 are eight hours offset by six.
 
 Dependent subtasks never move by themselves: `ripple` computes the cascade for
-the application to apply, or not, and `shiftTask` the moves of a whole order.
-`findings`, `overlaps` and `lateTransports` return what the schedule draws as
+the application to apply, or not, and `shiftTask` the moves of a whole task.
+`findings`, `overlaps` and `violatedDependencies` return what the schedule draws as
 data.
 
 Work that is not on the plan is dragged in from any list of the application,
@@ -84,7 +85,7 @@ subtask under the application's own id.
 left out where nothing would be readable. `appearance` adds what a colour
 cannot say - `"provisional"`, `"fixed"`, `"muted"`, `"open"` - and `progress`
 draws the share that is done as a rail along the bar. `route`, `anchor` and
-`ends` decide how a transport is drawn, per schedule or per transport, without
+`ends` decide how a dependency is drawn, per schedule or per dependency, without
 touching what a finding says.
 
 Each appearance owns exactly **one** property of the drawing, so several on one
@@ -92,12 +93,12 @@ bar stay several statements: `"provisional"` the fill (none at all, the surface
 shows through), `"fixed"` the ends (a cap inside each), `"muted"` the
 saturation (the task colour half mixed into the surface, at full height), and
 `"open"` a fade at whichever edge of the view the bar passes. `progress` owns a
-rail inside the main time. The faint, outlined fill belongs to a setup and a
-teardown and to nothing else.
+rail inside the main time. The faint, outlined fill belongs to a lead-in and a
+lead-out and to nothing else.
 
 ## Lanes that fold
 
-`<LaneGroup>` puts halls, lines and machine groups over the lanes, to any
+`<LaneGroup>` puts teams, depots or regions over the lanes, to any
 depth. A group is structure and never a lane: nothing sits on it, no finding is
 reported for it, and no intent names it (ADR-0025).
 
@@ -112,7 +113,7 @@ reported for it, and no intent names it (ADR-0025).
 ```
 
 Folded, a group becomes one row showing a **miniature** — every lane in it as a
-thin strip, the real work smaller. Transports still arrive at the right strip,
+thin strip, the real work smaller. Dependencies still arrive at the right strip,
 findings are still marked, and a strip can still be hovered and selected:
 folding costs a planner detail and never access. `collapsedGroups`,
 `defaultCollapsedGroups` and `onCollapsedGroupsChange` put the state in the
@@ -120,8 +121,8 @@ application's hands; it is a view state, never an intent.
 
 ## Reading and moving
 
-A tooltip on a hovered subtask or transport names the order, the times, setup
-and teardown and the findings; `tooltip` replaces its content or switches it
+A tooltip on a hovered subtask or dependency names the order, the times, lead-in
+and lead-out and the findings; `tooltip` replaces its content or switches it
 off. `now` draws the present across the lanes. The wheel over the schedule,
 lane headers included, scrolls the lanes and releases the page at their end,
 Ctrl or ⌘ and a pinch zoom, Shift pans; on a touch screen one finger pans and a
@@ -130,6 +131,26 @@ phone the plot keeps the larger part;
 `onDomainChange` reports the visible span, and a ref handle turns a client
 point into a time and a lane and back.
 
+## Blocked time
+
+`<BlockedTimes data={…} />` takes the time a lane is not available — leave,
+maintenance — as plain data, `{ id, lane, from, to, label? }`. It is drawn
+hatched behind the work; a subtask that covers some of it is a finding
+(`inBlockedTime`, and the third argument of `findings`), and a drag does not
+put work into it.
+
+## Not yet
+
+What the schedule does not do today, and waits for a caller who needs it (what
+it never does stands in ADR-0032):
+
+* **Milestones** — a point in time on a lane, drawn as a mark rather than a bar.
+* **Stacked overlap** — overlapping subtasks packed into sub-lanes on request;
+  today an overlap is always drawn offset, as the finding it is.
+* **Dependencies across tasks** — a dependency joins two subtasks of one task.
+
+Done from this list: **blocked time** per lane.
+
 ## Where to read on
 
 * The demo: <https://romanhaendler.github.io/umriss-ui/schedule/>, or locally
@@ -141,8 +162,8 @@ point into a time and a lane and back.
   with its examples' source, its props tables and why it is built as it is,
   and the declaration of every other export. Online, for the latest version:
   <https://romanhaendler.github.io/umriss-ui/schedule/llms.txt>.
-* The vocabulary — **Task**, **Subtask**, **Setup**, **Teardown**,
-  **Transport**, **Late transport**, **Lane header**, **Lane group**,
+* The vocabulary — **Task**, **Subtask**, **Lead-in**, **Lead-out**,
+  **Dependency**, **Violated dependency**, **Blocked time**, **Lane header**, **Lane group**,
   **Miniature**, **Intent**, **Ghost** — stands in the workspace's
   `CONTEXT.md`, section "The schedule".
 * [`../../docs/design-language.md`](../../docs/design-language.md) — the design