What you can do

Recalculate a project plan

One button on the project's Gantt chart. The solver takes the task network as it stands and finds dates that satisfy all of it at once:

Dependencies of all four kinds - finish-to-start, start-to-start, finish-to-finish and start-to-finish.
People's capacity - nobody is booked beyond what they have, counted in tasks, in hours or as a share of a working week.
Earliest starts - a task that cannot begin before a delivery arrives does not.
Hard finishes - a date the task must end by.
Deadlines - a target the plan tries to meet and reports when it cannot.

A task can need more than one person, and the plan respects each of them.

Change as little as possible

A recalculated plan that moves everything is as useless as one that moves nothing. Two rules keep it steady:

Started work is pinned. Tasks in progress or done stay where they are. The switch is on by default and can be turned off for a full replan.
Tasks with slack stay put. If a task does not have to move, it does not, so the new plan reads as a list of real changes rather than a new plan.

What the plan optimises for is an organisation setting: finish as early as possible, or disturb the current plan as little as possible.

See it before it changes

Preview. The new dates are shown next to the current ones. Nothing is written yet.
Apply. The plan is written into the project's tasks. If anybody changed the project while the preview was open, apply refuses instead of overwriting their change with a plan built without it.
Undo. A whole run is reversed in one step.

Understand why

When no plan is possible, you get the reason, not an error: the rules that could not be met, heaviest first, with the resource, the day and the amount. The plan is not written.
The critical path is drawn over the Gantt chart: the chain of tasks where any delay moves the finish.
Resource load shows each person's booking over time as a heatmap, with the tasks behind every cell, so overload is visible weeks before it happens.
A baseline keeps the approved plan to compare against as the real one moves.

Reassign work on the timeline

In the team view each person is a row and each task a block. Drag a block along the row to move it in time; drag it onto another person to reassign it. The change is written to the project directly.

Build a shift roster

The same engine plans people instead of tasks:

Coverage requirements - how many people with which skill are needed, when.
Skills - who is qualified for what.
Unavailability - holidays, sick leave, training.

Generate the roster, check it against the requirements, adjust it by hand - drag a shift to another day or another person, edit its hours in place - and publish it. After the week, the timesheet records what was actually worked next to what was planned.

The roster is one widget for pages and portals with a mode switch: shifts, or a project's people and tasks. The same screen serves the store manager planning next week and the project manager balancing a team, and it can be placed in any application.

Through the assistant

The recalculation is also a tool the assistant can run for you in chat: "recalculate the schedule for this project and tell me what moved". It acts as you, with your access, and the answer includes the explanation when a plan is not feasible.

It is deliberately a tool for a person, not for an AI employee working on its own: moving a whole project's dates is a decision somebody should own. See Under the hood.

Under the hood - the solver, the preview-and-apply contract, and who is allowed to recalculate.