scriptplan 0.10.1__tar.gz → 0.10.2__tar.gz

{scriptplan-0.10.1 → scriptplan-0.10.2}/CHANGELOG.md

@@ -1,5 +1,144 @@
 # Changelog
 
+## 0.10.2
+
+0.10.1 shipped two regressions. This release fixes them and the gaps 0.10.1 listed as
+not fixed. It also fixes the defects found while checking every example project
+against answers worked out without the engine, and the thirteen that Trace reported.
+Several plans that 0.10.1 scheduled silently and wrongly are now refused with an error
+that names the task and the date it cannot keep.
+
+### Regressions in 0.10.1
+
+- An alap `duration` or `length` task before a successor that starts inside a slot
+  ended after that successor started. Before a task starting at 16:20, a 1-hour
+  duration ran 16:00-17:00. It now runs 15:20-16:20. 0.10.0 put it at 15:00-16:00.
+- Time a task skipped to honour a mid-slot start or end was lost to every other task.
+  After an alap task that had to end at 14:30, a task free from 14:00 ran 15:00-16:00
+  instead of 14:30-15:30. Before a task declared to start at 09:30, a task free from
+  09:00 was pushed to 10:00 instead of using 09:00-09:30.
+
+Each booking now holds its own interval of the slot, so time a task skips stays free
+and a task that finishes early frees only what follows it.
+
+### Fixed: wrong schedules
+
+- A `duration` or `length` task after a task ending mid-slot started at the top of
+  that slot, before its predecessor finished. It now starts when the predecessor ends
+  and lasts its duration or length to the second.
+- A `duration` waited for working time. After a task ending Friday 17:00 a 2-hour
+  duration ran Monday 09:00-11:00, and it now runs Friday 17:00-19:00. An alap 2-hour
+  duration that had to end on a Sunday spanned 48 hours, and it now spans 2.
+- A task's finish depended on `timingresolution` when several people shared its last
+  slot, because only the first of them worked it. In `tutorial.tjp` the project ended
+  at 12:48, 12:00 or 11:44 depending on the slot size alone. All of them now work the
+  last slot, and the answer is the same at every resolution.
+- An alap milestone sat a slot before the moment it had to be at. Before a task
+  starting at 16:00 it was placed at 15:00. It now sits at 16:00, and one with no
+  successor sits at the project end.
+- An alap task did not keep the gap its successor asked for. With `gapduration 24h`
+  it ended where the successor began, and now it ends 24 hours earlier.
+- An alap task with an `end` of its own ignored its successors and could end after
+  one had started. It now ends by the earlier of the two.
+- An alap task whose successor states its start was moved to the project start, as
+  though nothing bounded it. It now ends as late as that start allows.
+- A `start` inherited from a container overrode the task's dependencies. It is now an
+  earliest start, and the task waits for what it depends on.
+
+### Fixed: silent wrong schedules are now errors
+
+Each of these exits non-zero with a message naming the task and both dates:
+
+- a task that would start before a task it depends on ends, including when its own
+  `start` says so, with or without a gap, and for milestones;
+- a stated `end` that a task scheduled as soon as possible, or its container, cannot
+  meet, which 0.10.1 overran by hours;
+- a stated `start` that an alap task cannot keep;
+- a stated start or end outside the project window. A start after the window used to
+  crash with "Error parsing project file: list index out of range", and an end after
+  it was clamped while the milestone was dated outside the project.
+
+An alap task that cannot fit before its deadline now names that deadline. A task
+whose successor failed is reported as blocked by it. 0.10.1 blamed the project window
+for the first, and moved the second to the start of the project, booked after the
+deadline.
+
+### Fixed: other
+
+- A reference that could mean two tasks with the same id bound whichever came first.
+  It is now an error that lists both.
+- `getAllocatedTime()` and timesheet figures credited a shared slot to the last task
+  booked in it. 40, 13 and 40 minutes in one hour read as 0, 0 and 2 hours, and now
+  read as 0.67, 0.22 and 0.67.
+- Each `ProjectFileParser()` compiled the grammar again (about 0.7 s). The grammar is
+  now compiled once per process.
+- The `plan` CLI scheduled every project twice and reported any exception raised
+  while scheduling as a parse error. It now schedules each project once and reports
+  a scheduling exception as a scheduling error.
+- Projects scheduled in parallel threads shared one message list, one error count
+  and one switch that turns error collection on. When one thread finished scheduling,
+  another thread's error could raise `TjRuntimeError` out of `schedule()` instead of
+  making it return False, and an error in one project could fail another. Each thread
+  now has its own messages, error count and switch.
+- An `effort` task with no resource allocated was reported as running outside the
+  project window because it "needs more time or more resource availability". It is now
+  reported as having effort but no resource to do it.
+- `plan report` printed every engine error as "Error: Error: …". It now prints one
+  "Error:".
+
+### Documentation
+
+- README described `onstart` as one reading for both directions. For a task scheduled
+  as soon as possible it is start-to-start. For one scheduled as late as possible it
+  means the task must finish before the predecessor starts.
+- README now says that `length` and `gaplength` count the project's working time, how
+  an alap task's end is bounded, and that unkept stated dates are errors.
+- README listed `maxgaplength` among the checked constraints. The syntax has never
+  accepted it, and the claim is removed.
+
+### Schedules that move
+
+A plan whose dates all fall on its slot grid, with no alap milestones and no
+`duration` across non-working time, schedules as it did in 0.10.1. Of the 24 example
+projects, 22 schedule identically:
+
+- `tutorial.tjp`: `spec` ends 14:20 instead of 15:00 on 24 January because three
+  developers finish it together, and every task after it moves with it. The project
+  ends on 18 April at 11:44 instead of 12:48.
+- `jit_supply.tjp`: the alap milestone `connection_setup.set_deps` sits at 2025-07-18
+  08:00, when `pack` starts, instead of 2025-07-17 16:00.
+
+### Internal API
+
+`ResourceScenario.reserve()` returns a list of `SlotBooking`, one per free stretch it
+books. The slot ledger is `slotIntervals`, and `slotFrontUsed` and `slotBackUsed` from
+0.10.1 are gone. Failure handling moved to `scriptplan.scheduler.stalls`, and stated
+dates are tracked in `scriptplan.core.declared_dates`. `slotSecondsUsed` is now
+exactly the sum of `slotTaskUsage` for every slot.
+
+### Verification
+
+The golden snapshots record what the engine produced last time. They catch a change
+but not an error, and 0.10.1 passed all of them. `examples/` now holds an answer for every
+task in the 24 showcase projects and in 24 edge cases, each derived by hand from
+the file and the documented semantics without running ScriptPlan, and compared with an
+hour-level reference scheduler wherever it accepts the file. `tests/test_examples.py`
+runs each project through the `plan` CLI and compares every task to the second. Every
+project passes on 0.10.2, and 13 of the edge cases fail on 0.10.1.
+
+`audit/evaluations/probe_placement.py` generates 300 plans that mix effort, duration,
+length and milestones in both directions. It checks that every dependency, stated date
+and span holds, that no slot is overfull, and that no task leaves free time it could
+have used. All 300 pass on 0.10.2, against 28 on 0.10.1 and 14
+on 0.10.0.
+
+`tests/test_threads.py` schedules five projects three times each in parallel threads
+and compares every date and message with the same project scheduled alone. It also
+forces one thread to leave error collection while another is still inside it. Its
+three tests fail on the 0.10.1 message handler.
+
+The full gate runs on Python 3.9 and 3.13.
+
 ## 0.10.1
 
 Tasks that shared a timing slot on one resource could be booked into time that
@@ -106,7 +245,7 @@ engine took the largest contribution in each slot rather than the sum, so the
 labour of every resource but one was booked, billed and discarded.
 
 Effort is now the amount of work to be done, and each allocated resource
-contributes its own time towards it, as TaskJuggler defines it. The same task
+contributes its own time towards it, as the .tjp format defines it. The same task
 with two resources finishes in half the time and costs what one resource's worth
 of work costs.
 

{scriptplan-0.10.1 → scriptplan-0.10.2}/MANIFEST.in

@@ -4,3 +4,4 @@ include CHANGELOG.md
 include pyproject.toml
 recursive-include scriptplan *.lark
 recursive-include scriptplan py.typed
+recursive-include examples *.tjp *.csv *.md

{scriptplan-0.10.1/scriptplan.egg-info → scriptplan-0.10.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: scriptplan
-Version: 0.10.1
+Version: 0.10.2
 Summary: A precise project scheduling engine with minute-level accuracy for resource allocation and dependency management.
 Author-email: Farshid Ashouri <farsheed.ashouri@gmail.com>
 Maintainer-email: Farshid Ashouri <farsheed.ashouri@gmail.com>
@@ -49,12 +49,12 @@ Dynamic: license-file
 
 # ScriptPlan
 
-![Tests](https://img.shields.io/badge/tests-411_passing-success?style=for-the-badge)
-![Probes](https://img.shields.io/badge/audit_probes-67_passing-success?style=for-the-badge)
+![Tests](https://img.shields.io/badge/tests-496_passing-success?style=for-the-badge)
+![Probes](https://img.shields.io/badge/audit_probes-85_passing-success?style=for-the-badge)
 ![Python](https://img.shields.io/badge/python-3.9%2B-blue?style=for-the-badge)
 ![Licence](https://img.shields.io/badge/licence-Apache--2.0-lightgrey?style=for-the-badge)
 
-A precise project scheduling engine with minute-level accuracy for resource allocation and dependency management. The syntax is compatible with TaskJuggler (.tjp files).
+A precise project scheduling engine with minute-level accuracy for resource allocation and dependency management. It reads projects written in the .tjp format.
 
 ## Installation
 
@@ -131,6 +131,10 @@ for task in project.tasks:
         print(f"{task.id}: {start} -> {end}")
 ```
 
+Projects can be parsed and scheduled in parallel threads. Messages and the error
+count belong to the thread that produced them, so read
+`get_message_handler_instance().messages` in the thread that called `schedule()`.
+
 ## What is verified
 
 Each behaviour below has a probe in `audit/evaluations/` that drives ScriptPlan
@@ -168,12 +172,22 @@ audit/evaluations/run_all.sh
 **Scheduling**
 
 - ASAP and ALAP, including chains that mix the two.
+- A task scheduled as late as possible ends by the earliest of its own `end`, the
+  start of each successor (less any gap that successor asks for) and the project
+  end. With none of these but a successor scheduled as soon as possible that
+  states no start, it is scheduled as soon as possible instead, with a warning.
 - Contention is resolved by priority, then criticalness, then declaration order.
 - The declared project period is never rewritten. A task that does not fit is
-  reported, with its name and the reason.
+  reported, with its name and the reason. A date stated outside the period is an
+  error.
 - Scheduling the same project twice produces the same dates and the same bookings.
-- `maxgapduration`, `maxgaplength`, `maxstart`, `minstart`, `maxend` and `minend`
-  are checked once the schedule is complete, and a violation is an error.
+- A stated `start` or `end` that the schedule cannot keep, and a task that would
+  start before something it depends on finishes, are errors.
+- `length` and `gaplength` count the project's working time, not a resource's:
+  a resource on longer hours does not shorten the gap.
+- `maxgapduration`, `maxstart`, `minstart`, `maxend` and `minend` are checked
+  once the schedule is complete, and a violation is an error. (`maxgaplength` is
+  not part of the syntax and is refused when parsed.)
 
 **Honesty**
 
@@ -191,9 +205,15 @@ audit/evaluations/run_all.sh
   rejected at parse time rather than silently producing nothing.
 - Accounts are parsed but not yet modelled, so `chargeset` and `charge` record an
   amount without posting it anywhere.
-- `onstart` dependencies are read as "the dependent task must finish before the
-  predecessor starts", which is ScriptPlan's own reading rather than
-  TaskJuggler's start-to-start one.
+- A task reference is first looked up from the referring task's scope, one level
+  up for each `!`. When that finds nothing but exactly one task in the project has
+  that id, the reference binds to it, so `depends !!pack` inside `delivery` finds
+  `delivery.pack`. When two tasks could be meant, the file is refused and both are
+  named.
+- `onstart` on a dependency means start-to-start for a task scheduled as soon as
+  possible: it may start once the predecessor starts. For a task scheduled as
+  late as possible it means the task must finish before the predecessor starts,
+  which is ScriptPlan's own reading.
 
 ## Example Project
 
@@ -266,17 +286,12 @@ Apache-2.0
 
 ## Acknowledgments
 
-ScriptPlan references [TaskJuggler](https://taskjuggler.org/) solely for **file format compatibility**. We have not used, modified, or copied any TaskJuggler source code. ScriptPlan is an independent, clean-room implementation.
-
-- The `.tjp` file format is documented publicly and widely used in the project management community
-- All scheduling algorithms, parser, and report generation in ScriptPlan are original implementations
-- TaskJuggler is mentioned only to indicate that ScriptPlan can read the same project file format
-
-If you're looking for the original TaskJuggler with its full feature set including interactive HTML reports and GUI tools, please visit [taskjuggler.org](https://taskjuggler.org/).
+ScriptPlan reads the .tjp project file format. It contains no code from any other
+scheduler: the parser, the scheduling algorithms and the reports are its own.
 
 ## Why ScriptPlan?
 
-This scheduler is part of Highway Workflow Engine's worker capacity management system. I decided to open-source it for the community to benefit from its precise scheduling capabilities. Thanks to TaskJuggler's established syntax, users can easily adopt ScriptPlan without learning a new format.
+This scheduler is part of Highway Workflow Engine's worker capacity management system. I decided to open-source it for the community to benefit from its precise scheduling capabilities. Because it reads the established .tjp syntax, users can adopt ScriptPlan without learning a new format.
 
 Yours,
 Farshid.

{scriptplan-0.10.1 → scriptplan-0.10.2}/README.md

@@ -4,12 +4,12 @@
 
 # ScriptPlan
 
-![Tests](https://img.shields.io/badge/tests-411_passing-success?style=for-the-badge)
-![Probes](https://img.shields.io/badge/audit_probes-67_passing-success?style=for-the-badge)
+![Tests](https://img.shields.io/badge/tests-496_passing-success?style=for-the-badge)
+![Probes](https://img.shields.io/badge/audit_probes-85_passing-success?style=for-the-badge)
 ![Python](https://img.shields.io/badge/python-3.9%2B-blue?style=for-the-badge)
 ![Licence](https://img.shields.io/badge/licence-Apache--2.0-lightgrey?style=for-the-badge)
 
-A precise project scheduling engine with minute-level accuracy for resource allocation and dependency management. The syntax is compatible with TaskJuggler (.tjp files).
+A precise project scheduling engine with minute-level accuracy for resource allocation and dependency management. It reads projects written in the .tjp format.
 
 ## Installation
 
@@ -86,6 +86,10 @@ for task in project.tasks:
         print(f"{task.id}: {start} -> {end}")
 ```
 
+Projects can be parsed and scheduled in parallel threads. Messages and the error
+count belong to the thread that produced them, so read
+`get_message_handler_instance().messages` in the thread that called `schedule()`.
+
 ## What is verified
 
 Each behaviour below has a probe in `audit/evaluations/` that drives ScriptPlan
@@ -123,12 +127,22 @@ audit/evaluations/run_all.sh
 **Scheduling**
 
 - ASAP and ALAP, including chains that mix the two.
+- A task scheduled as late as possible ends by the earliest of its own `end`, the
+  start of each successor (less any gap that successor asks for) and the project
+  end. With none of these but a successor scheduled as soon as possible that
+  states no start, it is scheduled as soon as possible instead, with a warning.
 - Contention is resolved by priority, then criticalness, then declaration order.
 - The declared project period is never rewritten. A task that does not fit is
-  reported, with its name and the reason.
+  reported, with its name and the reason. A date stated outside the period is an
+  error.
 - Scheduling the same project twice produces the same dates and the same bookings.
-- `maxgapduration`, `maxgaplength`, `maxstart`, `minstart`, `maxend` and `minend`
-  are checked once the schedule is complete, and a violation is an error.
+- A stated `start` or `end` that the schedule cannot keep, and a task that would
+  start before something it depends on finishes, are errors.
+- `length` and `gaplength` count the project's working time, not a resource's:
+  a resource on longer hours does not shorten the gap.
+- `maxgapduration`, `maxstart`, `minstart`, `maxend` and `minend` are checked
+  once the schedule is complete, and a violation is an error. (`maxgaplength` is
+  not part of the syntax and is refused when parsed.)
 
 **Honesty**
 
@@ -146,9 +160,15 @@ audit/evaluations/run_all.sh
   rejected at parse time rather than silently producing nothing.
 - Accounts are parsed but not yet modelled, so `chargeset` and `charge` record an
   amount without posting it anywhere.
-- `onstart` dependencies are read as "the dependent task must finish before the
-  predecessor starts", which is ScriptPlan's own reading rather than
-  TaskJuggler's start-to-start one.
+- A task reference is first looked up from the referring task's scope, one level
+  up for each `!`. When that finds nothing but exactly one task in the project has
+  that id, the reference binds to it, so `depends !!pack` inside `delivery` finds
+  `delivery.pack`. When two tasks could be meant, the file is refused and both are
+  named.
+- `onstart` on a dependency means start-to-start for a task scheduled as soon as
+  possible: it may start once the predecessor starts. For a task scheduled as
+  late as possible it means the task must finish before the predecessor starts,
+  which is ScriptPlan's own reading.
 
 ## Example Project
 
@@ -221,17 +241,12 @@ Apache-2.0
 
 ## Acknowledgments
 
-ScriptPlan references [TaskJuggler](https://taskjuggler.org/) solely for **file format compatibility**. We have not used, modified, or copied any TaskJuggler source code. ScriptPlan is an independent, clean-room implementation.
-
-- The `.tjp` file format is documented publicly and widely used in the project management community
-- All scheduling algorithms, parser, and report generation in ScriptPlan are original implementations
-- TaskJuggler is mentioned only to indicate that ScriptPlan can read the same project file format
-
-If you're looking for the original TaskJuggler with its full feature set including interactive HTML reports and GUI tools, please visit [taskjuggler.org](https://taskjuggler.org/).
+ScriptPlan reads the .tjp project file format. It contains no code from any other
+scheduler: the parser, the scheduling algorithms and the reports are its own.
 
 ## Why ScriptPlan?
 
-This scheduler is part of Highway Workflow Engine's worker capacity management system. I decided to open-source it for the community to benefit from its precise scheduling capabilities. Thanks to TaskJuggler's established syntax, users can easily adopt ScriptPlan without learning a new format.
+This scheduler is part of Highway Workflow Engine's worker capacity management system. I decided to open-source it for the community to benefit from its precise scheduling capabilities. Because it reads the established .tjp syntax, users can adopt ScriptPlan without learning a new format.
 
 Yours,
 Farshid.

scriptplan-0.10.2/examples/README.md

@@ -0,0 +1,42 @@
+# Examples
+
+Each project here comes with the answer it should produce.
+
+- `showcase/` holds the 24 demonstration projects that `SHOWCASE.md` is built from:
+  airport upgrades, a 500-task chain on an irregular shift, time zones, quotas,
+  limits, mixed forward and backward plans.
+- `edge_cases/` holds one small project for each scheduling pattern that has gone
+  wrong in a release, such as several tasks sharing one hour of one person, a
+  backward task before a successor that starts mid-hour, or a declared start inside
+  a slot.
+- `simple.tjp` is a minimal starting point.
+
+## The answers
+
+Next to every project is `<name>.expected.csv`, with the start and end of every task
+in the project's own time zone, to the second, and `<name>.expected.md`, which shows
+how each date was worked out.
+
+The answers were derived by hand from the project file and the documented semantics,
+without running ScriptPlan. Where an hour-level reference scheduler accepts the file,
+its result was compared too. Where the two disagree, the reason is recorded: it books
+whole slots, so it can end a task later than ScriptPlan, which places work to the
+minute.
+
+In three projects the hand derivation and the engine first disagreed, and the notes
+record how each was settled. In `thermal` and `quota` the project's own header and its
+long-standing test specify the engine's answer. In `jit_supply` the engine moved in
+0.10.2 and two independent sources confirm the new date.
+
+## Checking them
+
+```bash
+pytest tests/test_examples.py                                  # this checkout
+SCRIPTPLAN_EXAMPLES_PYTHON=/path/to/venv/bin/python \
+    pytest tests/test_examples.py                              # an installed release
+```
+
+Each project runs through the `plan` CLI in a fresh process, and every task is
+compared with its answer. These answers are not the golden snapshots in
+`tests/golden/`. A snapshot records what the engine produced last time and catches a
+change; these files record what it should produce and catch an error.

scriptplan-0.10.2/examples/edge_cases/alap_before_declared_start.expected.csv

@@ -0,0 +1,5 @@
+id;start;end
+d;2026-10-19-12:30:00;2026-10-19-14:30:00
+l;2026-10-19-12:30:00;2026-10-19-14:30:00
+e;2026-10-19-14:00:00;2026-10-19-14:30:00
+x;2026-10-19-14:30:00;2026-10-19-15:30:00

scriptplan-0.10.2/examples/edge_cases/alap_before_declared_start.expected.md

@@ -0,0 +1,6 @@
+# alap_before_declared_start
+
+x is declared to start at 14:30 and depends on d, l and e, which are alap with no end of their own.
+x's stated start is a fixed moment, so each ends as late as it can before it: d and l 12:30-14:30, and e on
+the desk 14:00-14:30. x then starts at its declared 14:30 and runs to 15:30. 0.10.1 degraded d, l and e
+to asap and put them at the project start (issuedb #14).

scriptplan-0.10.2/examples/edge_cases/alap_before_declared_start.tjp

@@ -0,0 +1,8 @@
+project p "alap_before_declared_start" 2026-10-19 +2w {
+  timingresolution 60min
+}
+resource r0 "Desk" { workinghours mon - fri 9:00 - 17:00 }
+task d "D" { scheduling alap duration 2h }
+task l "L" { scheduling alap length 2h }
+task e "E" { scheduling alap effort 30min allocate r0 }
+task x "X" { depends d, l, e start 2026-10-19-14:30 effort 60min allocate r0 }

scriptplan-0.10.2/examples/edge_cases/alap_bounded_by_declared_starts.expected.csv

@@ -0,0 +1,5 @@
+id;start;end
+x;2026-10-19-14:00:00;2026-10-19-15:00:00
+y;2026-10-19-15:00:00;2026-10-19-16:00:00
+m;2026-10-19-14:00:00;2026-10-19-14:00:00
+n;2026-10-19-14:30:00;2026-10-19-14:30:00

scriptplan-0.10.2/examples/edge_cases/alap_bounded_by_declared_starts.expected.md

@@ -0,0 +1,6 @@
+# alap_bounded_by_declared_starts
+
+x and y are declared to start at 14:00 and 14:30; x holds the desk until 15:00, so y runs 15:00-16:00.
+The alap milestones m and n precede them and are bounded by the starts the file states: m at 14:00, n at
+14:30. Scheduling twice gives the same answer because the bound is the stated start, not a start a
+previous run wrote back.

scriptplan-0.10.2/examples/edge_cases/alap_bounded_by_declared_starts.tjp

@@ -0,0 +1,8 @@
+project p "alap_bounded_by_declared_starts" 2026-10-19 +2w {
+  timingresolution 60min
+}
+resource r0 "Desk" { workinghours mon - fri 9:00 - 17:00 }
+task x "X" { start 2026-10-19-14:00 effort 60min allocate r0 }
+task y "Y" { start 2026-10-19-14:30 effort 60min allocate r0 }
+task m "M" { scheduling alap precedes x }
+task n "N" { scheduling alap precedes y }

scriptplan-0.10.2/examples/edge_cases/alap_gapduration_before_successor.expected.csv

@@ -0,0 +1,5 @@
+id;start;end
+g;2026-11-04-13:00:00;2026-11-06-17:30:00
+g.a;2026-11-04-13:00:00;2026-11-04-17:00:00
+g.b;2026-11-05-17:00:00;2026-11-06-17:30:00
+g.m;2026-11-06-17:30:00;2026-11-06-17:30:00

scriptplan-0.10.2/examples/edge_cases/alap_gapduration_before_successor.expected.md

@@ -0,0 +1,6 @@
+# alap_gapduration_before_successor
+
+Everything is alap and g must end Fri 17:30, so m sits there. b's 480 minutes end at m: Friday allows
+450 of them (10:00-17:30) under the daily cap and Thursday the last 30 (17:00-17:30). a must end 24 hours
+before b starts, by Wed 17:00, and takes Wed 13:00-17:00. 0.10.1 ignored the gap and ended a where b
+began (trace's defect 1).

scriptplan-0.10.2/examples/edge_cases/alap_gapduration_before_successor.tjp

@@ -0,0 +1,15 @@
+project d "alap_gapduration_before_successor" 2026-11-02 +4w {
+  timingresolution 30min
+  scheduling alap
+}
+resource r1 "Analyst" {
+  workinghours mon - fri 8:30 - 17:30
+  timezone "Europe/London"
+  limits { dailymax 450min }
+}
+task g "Group" {
+  end 2026-11-06-17:30
+  task a "A" { effort 240min allocate r1  }
+  task b "B" { effort 480min allocate r1 depends !a { gapduration 1440min }  }
+  task m "Milestone" { milestone depends !b  }
+}

scriptplan-0.10.2/examples/edge_cases/alap_keeps_successor_gaps.expected.csv

@@ -0,0 +1,7 @@
+id;start;end
+b;2026-10-20-14:00:00;2026-10-20-15:00:00
+a;2026-10-20-13:00:00;2026-10-20-14:00:00
+c;2026-10-20-12:00:00;2026-10-20-13:00:00
+d;2026-10-20-15:00:00;2026-10-20-16:00:00
+e;2026-10-19-15:00:00;2026-10-19-16:00:00
+f;2026-10-20-11:00:00;2026-10-20-12:00:00

scriptplan-0.10.2/examples/edge_cases/alap_keeps_successor_gaps.expected.md

@@ -0,0 +1,8 @@
+# alap_keeps_successor_gaps
+
+Backward tasks end as late as their successors allow, less the gap each successor asks for.
+b holds the desk Tue 14:00-15:00, so a (alap, precedes b) runs 13:00-14:00. d starts Tue 15:00 and wants
+c finished 2 hours (calendar) before it: c ends 13:00 and runs 12:00-13:00. f starts Tue 11:00 and wants
+3 working hours after e: Tue 09:00-11:00 is 2 of them and Mon 16:00-17:00 the third, so e ends Mon 16:00
+and runs 15:00-16:00. Before 0.10.2 these alap tasks were moved to the project start, and once they were
+not, the gap was ignored (issuedb #19).

scriptplan-0.10.2/examples/edge_cases/alap_keeps_successor_gaps.tjp

@@ -0,0 +1,10 @@
+project p "alap_keeps_successor_gaps" 2026-10-19 +2w {
+  timingresolution 60min
+}
+resource r0 "Desk" { workinghours mon - fri 9:00 - 17:00 }
+task b "B" { start 2026-10-20-14:00 effort 1h allocate r0 }
+task a "A" { scheduling alap effort 1h allocate r0 precedes b }
+task c "C" { scheduling alap duration 1h }
+task d "D" { start 2026-10-20-15:00 depends c { gapduration 2h } effort 1h allocate r0 }
+task e "E" { scheduling alap duration 1h }
+task f "F" { start 2026-10-20-11:00 depends e { gaplength 3h } duration 1h }

scriptplan-0.10.2/examples/edge_cases/alap_milestones_exact.expected.csv

@@ -0,0 +1,6 @@
+id;start;end
+t;2026-10-19-16:00:00;2026-10-19-17:00:00
+m;2026-10-19-16:00:00;2026-10-19-16:00:00
+d;2026-10-19-14:00:00;2026-10-19-16:00:00
+t2;2026-10-19-15:30:00;2026-10-19-16:00:00
+m2;2026-10-19-15:30:00;2026-10-19-15:30:00

scriptplan-0.10.2/examples/edge_cases/alap_milestones_exact.expected.md

@@ -0,0 +1,5 @@
+# alap_milestones_exact
+
+t holds the desk 16:00-17:00, so t2 (end 16:30) must run before it: 15:30-16:00. An alap milestone
+sits at the latest moment its successor allows: m at t's start 16:00, m2 at t2's start 15:30. d ends at m,
+16:00, and lasts 2 hours: 14:00. 0.10.1 put m at 15:00 and m2 at 15:00 (issuedb #14).

scriptplan-0.10.2/examples/edge_cases/alap_milestones_exact.tjp

@@ -0,0 +1,9 @@
+project p "alap_milestones_exact" 2026-10-19 +2w {
+  timingresolution 60min
+}
+resource r0 "Desk" { workinghours mon - fri 9:00 - 17:00 }
+task t "T" { scheduling alap effort 60min allocate r0 end 2026-10-19-17:00 }
+task m "M" { scheduling alap precedes t }
+task d "D" { scheduling alap duration 2h precedes m }
+task t2 "T2" { scheduling alap effort 30min allocate r0 end 2026-10-19-16:30 }
+task m2 "M2" { scheduling alap precedes t2 }

scriptplan-0.10.2/examples/edge_cases/alap_onstart_reading.expected.csv

@@ -0,0 +1,5 @@
+id;start;end
+g;2026-11-05-13:00:00;2026-11-06-17:30:00
+g.a;2026-11-06-13:30:00;2026-11-06-17:30:00
+g.b;2026-11-05-13:00:00;2026-11-06-13:30:00
+g.m;2026-11-06-17:30:00;2026-11-06-17:30:00

scriptplan-0.10.2/examples/edge_cases/alap_onstart_reading.expected.md

@@ -0,0 +1,5 @@
+# alap_onstart_reading
+
+For a task scheduled as late as possible, `onstart` reads as: it must finish before the predecessor
+starts (README). a is bounded only by g's end: Fri 13:30-17:30. b must end by a's start, Fri 13:30:
+Friday has 210 minutes left under the cap (10:00-13:30) and Thursday gives the other 270 (13:00-17:30).

scriptplan-0.10.2/examples/edge_cases/alap_onstart_reading.tjp

@@ -0,0 +1,15 @@
+project d "alap_onstart_reading" 2026-11-02 +4w {
+  timingresolution 30min
+  scheduling alap
+}
+resource r1 "Analyst" {
+  workinghours mon - fri 8:30 - 17:30
+  timezone "Europe/London"
+  limits { dailymax 450min }
+}
+task g "Group" {
+  end 2026-11-06-17:30
+  task a "A" { effort 240min allocate r1  }
+  task b "B" { effort 480min allocate r1 depends !a { onstart }  }
+  task m "Milestone" { milestone depends !b  }
+}

scriptplan-0.10.2/examples/edge_cases/alap_own_end_before_successor.expected.csv

@@ -0,0 +1,5 @@
+id;start;end
+g;2026-11-05-13:00:00;2026-11-06-17:30:00
+g.a;2026-11-05-13:00:00;2026-11-05-17:00:00
+g.b;2026-11-05-17:00:00;2026-11-06-17:30:00
+g.m;2026-11-06-17:30:00;2026-11-06-17:30:00

scriptplan-0.10.2/examples/edge_cases/alap_own_end_before_successor.expected.md

@@ -0,0 +1,5 @@
+# alap_own_end_before_successor
+
+b runs Thu 17:00-Fri 17:30 as above. a has its own end, Fri 12:00, and must also end before b starts,
+Thu 17:00; the earlier wins. Thursday has 420 minutes left under the cap once b's 30 are booked, so a runs
+13:00-17:00. 0.10.1 ended a at its own end, after b had started (trace's defect 9).

scriptplan-0.10.2/examples/edge_cases/alap_own_end_before_successor.tjp

@@ -0,0 +1,15 @@
+project d "alap_own_end_before_successor" 2026-11-02 +4w {
+  timingresolution 30min
+  scheduling alap
+}
+resource r1 "Analyst" {
+  workinghours mon - fri 8:30 - 17:30
+  timezone "Europe/London"
+  limits { dailymax 450min }
+}
+task g "Group" {
+  end 2026-11-06-17:30
+  task a "A" { effort 240min allocate r1 end 2026-11-06-12:00 }
+  task b "B" { effort 480min allocate r1 depends !a   }
+  task m "Milestone" { milestone depends !b  }
+}

scriptplan-0.10.2/examples/edge_cases/alap_project_end_and_declared_end.expected.csv

@@ -0,0 +1,4 @@
+id;start;end
+m;2026-11-02-00:00:00;2026-11-02-00:00:00
+mm;2026-10-21-11:30:00;2026-10-21-11:30:00
+d;2026-10-21-09:30:00;2026-10-21-11:30:00

scriptplan-0.10.2/examples/edge_cases/alap_project_end_and_declared_end.expected.md

@@ -0,0 +1,5 @@
+# alap_project_end_and_declared_end
+
+The project runs 2026-10-19 +2w, so it ends 2026-11-02 00:00. An alap milestone with no successor and
+no end of its own sits at the project end. One declared to end at 11:30 sits at 11:30. An alap duration
+of 2 hours declared to end at 11:30 runs 09:30-11:30 (0.10.0: 09:00-11:30; 0.10.1: 10:00-11:30).

scriptplan-0.10.2/examples/edge_cases/alap_project_end_and_declared_end.tjp

@@ -0,0 +1,7 @@
+project p "alap_project_end_and_declared_end" 2026-10-19 +2w {
+  timingresolution 60min
+}
+resource r0 "Desk" { workinghours mon - fri 9:00 - 17:00 }
+task m "M" { scheduling alap }
+task mm "MM" { scheduling alap end 2026-10-21-11:30 }
+task d "D" { scheduling alap duration 2h end 2026-10-21-11:30 }

scriptplan-0.10.2/examples/edge_cases/alap_spans_before_mid_slot_successor.expected.csv

@@ -0,0 +1,5 @@
+id;start;end
+t4;2026-10-19-16:20:00;2026-10-19-17:00:00
+d4;2026-10-19-15:20:00;2026-10-19-16:20:00
+l4;2026-10-19-15:20:00;2026-10-19-16:20:00
+m4;2026-10-19-16:20:00;2026-10-19-16:20:00

scriptplan-0.10.2/examples/edge_cases/alap_spans_before_mid_slot_successor.expected.md

@@ -0,0 +1,5 @@
+# alap_spans_before_mid_slot_successor
+
+t4 (alap, 40 min, end 17:00) runs 16:20-17:00. Everything that precedes it must end by 16:20:
+the 1-hour duration and length tasks run 15:20-16:20, and the milestone sits at 16:20.
+0.10.1 placed d4 and l4 at 16:00-17:00, ending after t4 began: a regression (issuedb #13).