@critical-path/svelte 0.19.0 → 0.19.1

package/CHANGELOG.md

@@ -1,5 +1,14 @@
 # @critical-path/svelte
 
+## 0.19.1
+
+### Patch Changes
+
+- Updated dependencies [da622c9]
+  - @critical-path/core@0.52.0
+  - @critical-path/mcp@0.20.0
+  - @critical-path/client@0.25.2
+
 ## 0.19.0
 
 ### Minor Changes

package/dist/index.js

@@ -4535,6 +4535,8 @@ var bn = (e, t) => {
 	priority: I().describe("urgent, high, medium, low or none"),
 	assigneeId: X(I()),
 	dueDate: X(I()),
+	deadline: X(I()).describe("Latest acceptable finish, enforced by critical path analysis"),
+	isMilestone: X(R()).describe("A zero-duration checkpoint"),
 	estimatedHours: X(L()),
 	loggedHours: X(L()),
 	isBlocked: X(R())
@@ -4557,7 +4559,7 @@ var bn = (e, t) => {
 	projectId: I(),
 	title: I(),
 	dueDate: X(I())
-}).describe("A deliverable (milestone)"), kn = Y({
+}).describe("A deliverable"), kn = Y({
 	id: I(),
 	taskId: I(),
 	content: I(),
@@ -4573,20 +4575,24 @@ var bn = (e, t) => {
 }), jn = Y({
 	taskId: I(),
 	isCritical: R().describe("True when any delay to this task delays the project end"),
-	totalSlack: L().describe("Slack in hours; 0 means critical"),
+	totalSlack: L().describe("Slack in hours; 0 means critical, negative means a deadline is missed by that much"),
 	slackWorkingHours: X(L()).describe("Slack in working hours on the task calendar"),
 	earlyStartDate: X(I()),
 	earlyFinishDate: X(I()),
 	lateStartDate: X(I()),
 	lateFinishDate: X(I()),
 	levelingDelayHours: X(L()).describe("With levelling: hours spent waiting for the assignee"),
-	waitingOn: X(I()).describe("With levelling: the task this one waited for")
+	waitingOn: X(I()).describe("With levelling: the task this one waited for"),
+	isMilestone: X(R()).describe("True for a milestone"),
+	deadlineDate: X(I()).describe("The task's deadline as an instant"),
+	deadlineVarianceHours: X(L()).describe("Working hours from forecast finish to deadline; negative means it will be missed")
 }), Mn = Y({
 	projectId: I(),
 	projectStartDate: X(I()),
 	projectEndDate: X(I()).describe("Forecast finish date"),
 	totalDurationHours: L(),
-	criticalTaskIds: z(I()).describe("Tasks with zero slack, in schedule order"),
+	criticalTaskIds: z(I()).describe("Tasks with zero or negative slack, in schedule order"),
+	missedDeadlineTaskIds: X(z(I())).describe("Tasks forecast to finish after their deadline"),
 	tasks: z(jn),
 	leveled: X(R()),
 	unleveledProjectEndDate: X(I()).describe("With levelling: the end date before levelling"),
@@ -4686,7 +4692,7 @@ var bn = (e, t) => {
 	{
 		name: "analyze-schedule",
 		description: "Find what drives a project's end date, how much each task can slip and where people are double-booked, then recommend fixes. Use for \"when will we finish?\", \"what is critical?\" or deadline-risk questions.",
-		content: "---\nname: analyze-schedule\ndescription: Find what drives a project's end date, how much each task can slip and where people are double-booked, then recommend fixes. Use for \"when will we finish?\", \"what is critical?\" or deadline-risk questions.\n---\n\n# Analyze the schedule\n\n## 1. Run the schedule\n\n1. Get the `projectId` (`list_projects`).\n2. Call `calculate_critical_path` with `calendars: \"assignee\"` and `levelResources: true`, so each person works on one task at a time on their own calendar. If the user wants the ideal schedule with unlimited people, call it with no options instead.\n3. If the question spans projects that share people, call `calculate_portfolio_critical_path` with their `projectIds` (and `projectOrder` if the user ranked them) instead.\n4. For in-flight projects, pass `effort: \"remaining\"` so finished hours are not scheduled again.\n\n## 2. Read the result\n\n- `projectEndDate` is the forecast finish. With levelling, compare it with `unleveledProjectEndDate`: the gap is time lost waiting for busy people.\n- `criticalTaskIds` are the tasks with zero slack. Any delay to one of them moves the end date.\n- Each entry in `tasks` has `slackWorkingHours`: how many working hours the task can slip without moving the end. Under about 8 hours is near-critical.\n- `levelingDelayHours` and `waitingOn` show a task that waited for its assignee to finish another task.\n- `overallocations` lists periods where a person (`assigneeId`) or team (`teamId`) is booked above `capacity`; `allocation` 1.5 means 150%.\n\nLook up titles for the task ids you mention with `get_task` or `list_tasks`; report titles, not ids. To see why a critical task cannot start earlier, call `get_task` with `includeDependencies: true`: `dependencies.dependsOn` lists what it waits for and `dependencies.dependents` what waits for it.\n\n## 3. Recommend\n\nRank fixes by how much they pull the end date in:\n\n1. **Unblock critical tasks.** A critical task with `isBlocked: true` delays everything; say what it waits for.\n2. **Move work off the bottleneck person.** If critical tasks wait on one assignee (`waitingOn`), suggest reassigning a non-critical task of theirs.\n3. **Remove false dependencies.** A critical task waiting on work it does not really need (`dependencies.dependsOn`) can start earlier once the link is removed.\n4. **Split long critical tasks** so parts can run in parallel.\n5. **Cut or defer** tasks feeding late deliverables, if dates are fixed.\n\nShow the recommendation to the user. Change tasks (`update_task`) or dependencies (`add_dependency`, `remove_dependency`) only when they ask, then run the schedule again to show the effect.\n\n## Report format\n\n- Forecast finish date, and against any deadline the user gave.\n- Critical path: task titles in order, with assignee.\n- Top risks: near-critical tasks, blocked critical tasks, over-allocations.\n- Recommended actions, each with its expected effect.\n"
+		content: "---\nname: analyze-schedule\ndescription: Find what drives a project's end date, how much each task can slip and where people are double-booked, then recommend fixes. Use for \"when will we finish?\", \"what is critical?\" or deadline-risk questions.\n---\n\n# Analyze the schedule\n\n## 1. Run the schedule\n\n1. Get the `projectId` (`list_projects`).\n2. Call `calculate_critical_path` with `calendars: \"assignee\"` and `levelResources: true`, so each person works on one task at a time on their own calendar. If the user wants the ideal schedule with unlimited people, call it with no options instead.\n3. If the question spans projects that share people, call `calculate_portfolio_critical_path` with their `projectIds` (and `projectOrder` if the user ranked them) instead.\n4. For in-flight projects, pass `effort: \"remaining\"` so finished hours are not scheduled again.\n\n## 2. Read the result\n\n- `projectEndDate` is the forecast finish. With levelling, compare it with `unleveledProjectEndDate`: the gap is time lost waiting for busy people.\n- `criticalTaskIds` are the tasks with zero or negative slack. Any delay to one of them moves the end date or misses a deadline.\n- `missedDeadlineTaskIds` lists tasks forecast to finish after their `deadline`. Their `deadlineVarianceHours` says by how much (negative working hours), and the negative `totalSlack` on the tasks before them shows which work drives the miss. Entries with `isMilestone: true` are checkpoints such as releases or sign-offs.\n- Each entry in `tasks` has `slackWorkingHours`: how many working hours the task can slip without moving the end. Under about 8 hours is near-critical.\n- `levelingDelayHours` and `waitingOn` show a task that waited for its assignee to finish another task.\n- `overallocations` lists periods where a person (`assigneeId`) or team (`teamId`) is booked above `capacity`; `allocation` 1.5 means 150%.\n\nLook up titles for the task ids you mention with `get_task` or `list_tasks`; report titles, not ids. To see why a critical task cannot start earlier, call `get_task` with `includeDependencies: true`: `dependencies.dependsOn` lists what it waits for and `dependencies.dependents` what waits for it.\n\n## 3. Recommend\n\nRank fixes by how much they pull the end date in:\n\n1. **Unblock critical tasks.** A critical task with `isBlocked: true` delays everything; say what it waits for.\n2. **Move work off the bottleneck person.** If critical tasks wait on one assignee (`waitingOn`), suggest reassigning a non-critical task of theirs.\n3. **Remove false dependencies.** A critical task waiting on work it does not really need (`dependencies.dependsOn`) can start earlier once the link is removed.\n4. **Split long critical tasks** so parts can run in parallel.\n5. **Cut or defer** tasks feeding late deliverables, if dates are fixed.\n\nShow the recommendation to the user. Change tasks (`update_task`) or dependencies (`add_dependency`, `remove_dependency`) only when they ask, then run the schedule again to show the effect.\n\n## Report format\n\n- Forecast finish date, and against any deadline the user gave. If the user gives a date that is not yet on a task, offer to record it as a `deadline` (on a milestone task with `isMilestone: true` if it is a checkpoint) so later runs track it.\n- Each milestone: forecast date against its deadline.\n- Critical path: task titles in order, with assignee.\n- Top risks: near-critical tasks, blocked critical tasks, over-allocations.\n- Recommended actions, each with its expected effect.\n"
 	},
 	{
 		name: "investigate-task",
@@ -4701,7 +4707,7 @@ var bn = (e, t) => {
 	{
 		name: "plan-project",
 		description: "Turn a goal, brief or feature list into a Critical Path project with deliverables, estimated and prioritized tasks, and the dependencies between them. Use when the user asks to plan, scope or break down work.",
-		content: "---\nname: plan-project\ndescription: Turn a goal, brief or feature list into a Critical Path project with deliverables, estimated and prioritized tasks, and the dependencies between them. Use when the user asks to plan, scope or break down work.\n---\n\n# Plan a project\n\nTurn a goal into deliverables (dated outcomes), tasks (estimated units of work) and dependencies (which task waits for which) the scheduler can use.\n\n## 1. Find or create the project\n\n1. Call `list_projects`. If a project already matches the goal, use it and read it with `get_project` to learn its workflow status keys and custom fields.\n2. Only if none fits, and the user wants a new one, call `create_project` with a `name` and a short `key`.\n3. Call `list_tasks` with the `projectId` and `list_deliverables` to see what already exists. Do not recreate it.\n\n## 2. Draft the plan before writing anything\n\nBreak the goal down in your reply first and show it to the user:\n\n- **Deliverables**: 2-6 outcomes someone could accept or reject, each with a due date if the user gave one.\n- **Tasks** under each deliverable. Each task:\n  - starts with a verb and is small enough for one person (about 2-24 hours);\n  - has `estimatedHours` (effort, not elapsed time);\n  - has a `priority`: `urgent` only for work that blocks others now, `high` for the critical outcome, `medium` by default, `low` for nice-to-haves;\n  - lists the tasks it must wait for (its dependencies). Only add a dependency when the work truly cannot start earlier; every extra one lengthens the schedule.\n- Note anything you assumed (team size, dates, scope) as a question.\n\nAsk the user to confirm or adjust before creating anything. A plan is cheap to change in chat and tedious to change once created.\n\n## 3. Create it\n\n1. Create tasks with `create_task` (`projectId`, `title`, `description` with acceptance criteria, `estimatedHours`, `priority`, `assigneeId` if known). Leave `status` out so tasks start in the workflow's default status.\n2. Create each deliverable with `create_deliverable`, passing the ids of its tasks in `taskIds`.\n3. Add each dependency from your plan with `add_dependency`: `taskId` is the task that waits, `dependsOnTaskId` the task that must finish first. Use the ids `create_task` returned. If one is refused as circular, your plan has a loop: fix the order with the user instead of retrying.\n4. If the project already had tasks, check what they wait for with `get_task` and `includeDependencies: true` before linking new work to them.\n\n## 4. Check the result\n\n1. Call `calculate_critical_path` for the project and report the forecast `projectEndDate` and the `criticalTaskIds` (by title). If every task is critical or the end date looks too early, a dependency is probably missing or reversed.\n2. If the end date misses a deliverable's due date, say so and suggest what to cut, split or reassign. The `analyze-schedule` skill covers this in depth.\n\n## Guardrails\n\n- Never invent user ids for `assigneeId`. Leave tasks unassigned unless the user named the person and you have their id.\n- Keep the plan to what the user asked for; propose extra work as suggestions, not tasks.\n"
+		content: "---\nname: plan-project\ndescription: Turn a goal, brief or feature list into a Critical Path project with deliverables, estimated and prioritized tasks, and the dependencies between them. Use when the user asks to plan, scope or break down work.\n---\n\n# Plan a project\n\nTurn a goal into deliverables (dated outcomes), tasks (estimated units of work) and dependencies (which task waits for which) the scheduler can use.\n\n## 1. Find or create the project\n\n1. Call `list_projects`. If a project already matches the goal, use it and read it with `get_project` to learn its workflow status keys and custom fields.\n2. Only if none fits, and the user wants a new one, call `create_project` with a `name` and a short `key`.\n3. Call `list_tasks` with the `projectId` and `list_deliverables` to see what already exists. Do not recreate it.\n\n## 2. Draft the plan before writing anything\n\nBreak the goal down in your reply first and show it to the user:\n\n- **Deliverables**: 2-6 outcomes someone could accept or reject, each with a due date if the user gave one.\n- **Milestones** for dated checkpoints (a release, a sign-off, a review): a task with `isMilestone: true`, a `deadline` if the date is fixed, and dependencies on the tasks that must finish first. The schedule then reports whether each date will be met.\n- **Tasks** under each deliverable. Each task:\n  - starts with a verb and is small enough for one person (about 2-24 hours);\n  - has `estimatedHours` (effort, not elapsed time);\n  - has a `priority`: `urgent` only for work that blocks others now, `high` for the critical outcome, `medium` by default, `low` for nice-to-haves;\n  - lists the tasks it must wait for (its dependencies). Only add a dependency when the work truly cannot start earlier; every extra one lengthens the schedule.\n- Note anything you assumed (team size, dates, scope) as a question.\n\nAsk the user to confirm or adjust before creating anything. A plan is cheap to change in chat and tedious to change once created.\n\n## 3. Create it\n\n1. Create tasks with `create_task` (`projectId`, `title`, `description` with acceptance criteria, `estimatedHours`, `priority`, `assigneeId` if known). Leave `status` out so tasks start in the workflow's default status.\n2. Create each deliverable with `create_deliverable`, passing the ids of its tasks in `taskIds`.\n3. Add each dependency from your plan with `add_dependency`: `taskId` is the task that waits, `dependsOnTaskId` the task that must finish first. Use the ids `create_task` returned. If one is refused as circular, your plan has a loop: fix the order with the user instead of retrying.\n4. If the project already had tasks, check what they wait for with `get_task` and `includeDependencies: true` before linking new work to them.\n\n## 4. Check the result\n\n1. Call `calculate_critical_path` for the project and report the forecast `projectEndDate` and the `criticalTaskIds` (by title). If every task is critical or the end date looks too early, a dependency is probably missing or reversed.\n2. If the end date misses a deliverable's due date, or `missedDeadlineTaskIds` is not empty, say so and suggest what to cut, split or reassign. The `analyze-schedule` skill covers this in depth.\n\n## Guardrails\n\n- Never invent user ids for `assigneeId`. Leave tasks unassigned unless the user named the person and you have their id.\n- Keep the plan to what the user asked for; propose extra work as suggestions, not tasks.\n"
 	},
 	{
 		name: "report-status",
@@ -4721,7 +4727,7 @@ function Vn(e) {
 //#region ../mcp/dist/tools/definitions.js
 var Hn = {
 	core: "Projects, tasks and task dependencies: find, read, create, update and delete",
-	collaboration: "Deliverables (milestones) and task comments",
+	collaboration: "Deliverables and task comments",
 	scheduling: "Critical path, portfolio scheduling and workload/capacity",
 	analytics: "Project status ladder, task metrics, earned value and progress history",
 	guidance: "Skills: step-by-step playbooks for multi-step jobs"
@@ -4907,6 +4913,8 @@ var tr = $({
 		]).optional().default("none").describe("Task priority"),
 		assigneeId: I().optional().describe("User ID to assign task to"),
 		dueDate: I().optional().describe("Due date (ISO string)"),
+		deadline: I().optional().describe("Latest acceptable finish (YYYY-MM-DD for the end of that working day, or an ISO date-time). Critical path analysis reports a miss as negative slack"),
+		isMilestone: R().optional().describe("Mark the task as a milestone: a zero-duration checkpoint (release, sign-off) fed by dependencies; its estimate is ignored"),
 		tags: z(I()).optional().describe("Tags for categorization"),
 		estimatedHours: L().optional().describe("Estimated hours to complete"),
 		allocation: L().gt(0).max(1).optional().describe("Share of the assignee's time the task takes, in (0, 1]; e.g. 0.5 for half-time. Estimates are effort, so a 0.5 task takes twice as long"),
@@ -4925,6 +4933,8 @@ var tr = $({
 			priority: e.priority || "none",
 			assigneeId: e.assigneeId,
 			dueDate: e.dueDate,
+			deadline: e.deadline,
+			isMilestone: e.isMilestone,
 			tags: e.tags || [],
 			estimatedHours: e.estimatedHours,
 			customFields: e.customFields,
@@ -4937,7 +4947,7 @@ var tr = $({
 }), nr = $({
 	name: "update_task",
 	title: "Update Task",
-	description: "Change an existing task: title, description, status, priority, assignee, due date, estimate, logged hours, allocation, blocked state, tags or custom fields. Only the fields you pass change. Use it to move a task through its workflow or re-plan it. Returns the updated task.",
+	description: "Change an existing task: title, description, status, priority, assignee, due date, deadline, milestone flag, estimate, logged hours, allocation, blocked state, tags or custom fields. Only the fields you pass change. Use it to move a task through its workflow or re-plan it. Returns the updated task.",
 	toolset: "core",
 	outputZodSchema: wn,
 	zodSchema: B({
@@ -4954,6 +4964,8 @@ var tr = $({
 		]).optional().describe("New priority"),
 		assigneeId: I().optional().describe("User ID to assign the task to"),
 		dueDate: I().optional().describe("Due date (ISO string)"),
+		deadline: I().optional().describe("Latest acceptable finish (YYYY-MM-DD for the end of that working day, or an ISO date-time). Critical path analysis reports a miss as negative slack"),
+		isMilestone: R().optional().describe("Mark the task as a milestone: a zero-duration checkpoint (release, sign-off) fed by dependencies; its estimate is ignored"),
 		tags: z(I()).optional().describe("Replaces all tags"),
 		estimatedHours: L().optional().describe("Estimated effort in hours"),
 		allocation: L().gt(0).max(1).optional().describe("Share of the assignee's time the task takes, in (0, 1]; e.g. 0.5 for half-time. Estimates are effort, so a 0.5 task takes twice as long"),
@@ -5031,7 +5043,7 @@ var tr = $({
 }), or = $({
 	name: "list_deliverables",
 	title: "List Deliverables",
-	description: "List a project's deliverables: milestones that group tasks toward a dated outcome. Use it to see what is due and which tasks feed each milestone. Returns { deliverables }.",
+	description: "List a project's deliverables: outputs that group the tasks producing them. Use it to see what is due and which tasks feed each deliverable. For dated checkpoints, look for milestone tasks (`isMilestone`). Returns { deliverables }.",
 	toolset: "collaboration",
 	outputZodSchema: B({ deliverables: z(On) }),
 	zodSchema: B({ projectId: I().optional().describe("Project ID (falls back to ambient context if omitted)") }),
@@ -5044,7 +5056,7 @@ var tr = $({
 }), sr = $({
 	name: "create_deliverable",
 	title: "Create Deliverable",
-	description: "Create a deliverable (milestone) in a project, optionally linking existing tasks by id. Use it when planning a dated outcome that several tasks build toward. Returns the created deliverable.",
+	description: "Create a deliverable in a project, optionally linking existing tasks by id. Use it for an output (a document, a build, an asset) that several tasks produce. For a dated checkpoint the schedule should enforce, create a task with `isMilestone: true` and a `deadline` instead. Returns the created deliverable.",
 	toolset: "collaboration",
 	outputZodSchema: On,
 	zodSchema: B({
@@ -5362,7 +5374,7 @@ var vr = [
 ];
 function yr(e, t = {}) {
 	let n = new Set(e.map((e) => e.name)), r = [
-		"Critical Path is a project management backend. A project holds tasks and deliverables (milestones that group tasks). Tasks have a workflow status, priority, assignee, effort estimate, logged hours, optional subtasks (parentId) and dependencies, and comments.",
+		"Critical Path is a project management backend. A project holds tasks and deliverables (outputs that group the tasks producing them). Tasks have a workflow status, priority, assignee, effort estimate, logged hours, optional subtasks (parentId) and dependencies, and comments. A task with `isMilestone: true` is a zero-duration checkpoint, and a `deadline` on any task is enforced by critical path analysis.",
 		"",
 		"Working rules:",
 		"- Never guess ids. Get them from list or create results.",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@critical-path/svelte",
-  "version": "0.19.0",
+  "version": "0.19.1",
   "description": "Svelte 5 Runes state and reactive integrations for Critical Path headless project management framework",
   "author": "Jack James",
   "license": "MIT",
@@ -18,9 +18,9 @@
     }
   },
   "dependencies": {
-    "@critical-path/client": "0.25.1",
-    "@critical-path/core": "0.51.1",
-    "@critical-path/mcp": "0.19.0"
+    "@critical-path/mcp": "0.20.0",
+    "@critical-path/client": "0.25.2",
+    "@critical-path/core": "0.52.0"
   },
   "peerDependencies": {
     "svelte": "^5.57.2"
@@ -30,7 +30,7 @@
     "@types/node": "^26.6.5",
     "svelte": "^5.57.2",
     "typescript": "^5.7.0",
-    "vite": "^8.3.4",
+    "vite": "^8.3.5",
     "vitest": "^3.0.0"
   },
   "engines": {