Back to results
Explore the library298 guides total · goals, work & tasks
By goal

Choose what you want to achieve.

By work or interest

Choose a setting you work or spend time in.

By task

Choose the kind of help you want.

Counts show all available guides. Filters combine to narrow your results.

Create work & incomeGuide

Plan a small project around dependencies and work windows

Fit fixed-owner tasks into agreed windows, then spot the dependency bottleneck that makes enough total hours still too little.

Illustrative resourceNot tool-testedAdults proposing a small project from agreed task owners, durations, prerequisites and availability
What you’re working towards

A readable two-day working proposal and reusable blank task/window worksheet, with exact owner capacity, dependency checks and separate no-fit, missing-input and cyclic-input outcomes. Real commitments remain subject to owner confirmation.

Download playbook .md

Your choice also saves this guide’s current worked-example checkmarks. Only this browser; no account or sync. View saved guides

Saving needs JavaScript. Reading and downloading this guide does not save it.

Included example · illustrative MD file

Download the two-day working plan

Editable Markdown schedule with exact handoffs, owner capacity, changed-case decisions and pending real-owner confirmations. Static synthetic proposal; no automatic recalculation.

Not tool-tested. Review and adapt before using it for a real project. Your browser may download this file when you choose View example file.

See the worked-example diagram
Owner-lane project capacity schedule for a synthetic welcome-pack project. Seven tasks with dependencies across Monday and Tuesday windows. Owner B is available Monday 10:00–11:00 only, with unused available time 10:00–10:30. Capacity totals A 150 of 180 minutes, B 90 of 150, combined 240 of 330. Changed case C1 has no fit, C2 is blocked on unknown source release, C3 is invalid due to a dependency cycle. Hatch marks unavailable time; grey marks unused availability — not colour alone.

Download the diagram text

Unused time before a handoff may not help after it. The baseline ends exactly at the deadline; shortening A’s Tuesday window leaves no fit despite enough total minutes. Synthetic fixed-owner proposal; real estimates and owner agreement still need confirmation.

Source files to work with

Make a start

One step at a time.

6 steps

Start with the synthetic worked example or other non-sensitive inputs. Run one prompt at a time in your chosen AI tool. Replace any bracketed placeholders with the requested material, check each reply, and supply the source or earlier outputs that step needs. Paste them again if the tool lacks that context.

Set up the worked example

Open

Open a fresh text-AI chat, a plain-text editor and a calculator for minutes. Download project-capacity-worksheet.md and save a copy as my-project-worksheet.md. The files are editable text, not a scheduler; do not open or connect a calendar.

Add the sample

Open project-capacity-source.md, or copy the entire “The starting point” (Synthetic input), into step 1’s COMPLETE SOURCE field, including P1, W1/W2, R1/R2, T1–T7, C1–C3 and O1. Step 2 needs that unchanged source plus your worksheet. Step 3 uses the complete validated baseline source; keep C1–C3 as separate later cases. Save the proposed schedule as my-project-plan.md and reopen it. Step 4 needs the original source and reopened schedule. Step 5 uses the complete original source and treats each listed change independently, never cumulatively. Step 6 needs the source, checked proposal, your independent audit and all three change analyses. Save and reopen its final plan and verification note together in my-project-plan.md. “The intended result” (Illustrative output), reasoning and result JSON are comparison answers. The optional advanced exercise remains in the sample chat: supply the complete original source, one explicit fictional practice change and confirmed unchanged inputs. Label any practice approval fictional; do not infer real owner consent. A new chat needs the full context again.

Start with the synthetic example, then adapt each prompt to your task.

01

Copy the inputs before trying to fill a calendar

Start with the blank worksheet and complete source. Every task needs a fixed owner, indivisible duration and prerequisites; every owner needs confirmed work windows. Preserve the source release, Tuesday 10:30 deadline and limited review scope. A blank release time is unknown, not permission to start.

Your starting prompt
Organize the supplied small-project input into a task and work-window worksheet. Keep the original source unchanged and preserve every source ID. Record one owner, exact duration, prerequisite IDs, required source availability and approval status per task. Record each owner's separate date/start/end windows and the exact deadline on the supplied clock. Preserve start-grid, indivisibility and no-overlap rules, excluded scope and the supplied review/revision limit. Mark missing values unknown. Do not invent a release time, new owner, estimate, approval, extra window or calendar commitment. Do not schedule yet.

COMPLETE SOURCE:
[paste complete source]
Expect

A source-linked task/window worksheet with seven tasks, fixed owners, durations, prerequisites, release, deadline and review limits; no schedule yet.

Check

There are four supplied owner windows on 19/20 October 2026. T1’s facts release Monday 09:00; the deadline is Tuesday 10:30 on the same local clock. T6 waits for both T4 and T5. Preserve half-hour starts, indivisible tasks and R2’s limited revision work.

If it differs

If an ID, dependency, date or confirmation is missing, compare with the source and correct the worksheet before scheduling. Use unknown for a missing release, not Monday 09:00. Do not turn the fictional agreement into real owner approval.

02

Separate missing inputs from an invalid dependency graph

Check known task IDs and follow every dependency before placing work. Missing source availability blocks a conclusion. Adding T6 as a prerequisite of T2 creates a cycle through T3 and T4; the source owner must resolve it. Neither condition is a proven no-fit result for a complete, consistent model.

Your starting prompt
Validate the worksheet against the unchanged source. Require positive durations, known owners, confirmed non-overlapping work windows, a deadline, known prerequisites and any required source release. Detect duplicate or unknown task IDs, unknown owners and cyclic dependencies. Show the actual cycle if one exists. Keep four outcomes distinct: ready = a valid checked proposal; blocked = required information missing; no fit = complete valid inputs plus a sound impossibility proof or exhaustive search; invalid = contradictory or malformed model. Do not guess missing values or remove an edge. For a blocked or invalid input, state the exact question for the source owner and stop scheduling that scenario.

SOURCE AND WORKSHEET:
[paste]
Expect

A baseline validation result that checks known IDs, required inputs, non-overlapping windows and an acyclic dependency graph.

Check

The baseline is valid input, but a ready proposal still needs a checked schedule. Missing required facts mean blocked; contradictory input such as a cycle means invalid. No fit requires complete valid inputs and a sound proof or exhaustive search, not merely an unsuccessful guess.

If it differs

If a required source/window is unconfirmed, ask the exact missing question and stop that scenario. If a cycle appears, show its edges and ask the source owner to resolve it; do not delete a prerequisite to get an answer.

03

Place uninterrupted tasks after their handoffs

In the example, T1 and T2 use A on Monday morning, then B reviews T3 at 10:30. On Tuesday, A applies notes while B checks links, both at 09:00. T6 waits until both finish at 09:30; B checks the assembled copy at 10:00.

Your starting prompt
For complete, valid inputs only, propose one schedule using the supplied task owners, durations and start grid. Place each task exactly once as one uninterrupted block inside one of that owner's agreed windows. Every predecessor must finish no later than the task starts; source release and deadline also constrain placement. Do not overlap tasks for the same owner. Parallel work by different owners is allowed only when prerequisites permit it. Return a readable table with date, start, finish, owner, task ID, work and prerequisite/release check, plus source references. Keep the result a proposal; do not create calendar events or assign real commitments. If you cannot find a fit, distinguish an unverified search from a proven no-fit result.

VALIDATED SOURCE:
[paste]
Expect

A seven-row proposal with full dates, start/end, original owner and handoff checks. Save it as my-project-plan.md.

Check

Monday: A T1 09:00–09:30, A T2 09:30–10:30, B T3 10:30–11:00. Tuesday: A T4 and B T5 09:00–09:30, A T6 09:30–10:00, B T7 10:00–10:30. T4/T5 can overlap because owners differ; T6 waits for both.

If it differs

If a task is split, moved to another owner, omitted or started before a handoff, request a complete corrected proposal using the unchanged constraints. A matching table is not an observed delivery or owner commitment. Reopen the saved plan before its audit.

04

Count minutes and check when they are usable

A needs 150 minutes and has 180; B needs 90 and has 150. The unused 90 combined minutes do not all occur after the relevant handoffs. A cannot apply notes in Monday’s spare half hour because the review finishes at 11:00, exactly when A’s window ends.

Your starting prompt
Audit the proposed schedule independently against the complete source. Recalculate owner work totals and usable window totals without double-counting overlaps or time after the deadline. Show unused intervals as well as totals. For every task, verify original owner/duration, half-hour start, whole-window containment, source release, all prerequisite finish times, no same-owner overlap and finish by the deadline. Check every task appears exactly once. Explain why capacity before a prerequisite is not interchangeable with capacity after it and why another owner's time cannot cover a fixed assignment. Report any failed check and retain the original inputs.

SOURCE:
[paste]

CANDIDATE SCHEDULE:
[paste]
Expect

An independent row-by-row schedule check and owner totals with the exact unused intervals.

Check

A works 150 of 180 minutes; B 90 of 150. Unused: A Monday 10:30–11:00, B Monday 10:00–10:30 and Tuesday 09:30–10:00. A’s spare Monday interval cannot do T4 before T3 finishes at 11:00. T7 finishes exactly at Tuesday’s deadline, with no completion buffer.

If it differs

Recalculate durations and every predecessor’s end against each start yourself. If the AI only repeats a passed label, request the actual endpoints and source IDs. Correct a new saved schedule and recheck all dependencies, windows and totals, not only the changed row.

05

Test the shorter window without silently changing the job

A’s Tuesday window shrinks to 09:00–09:30. A still has 150 total minutes, but T4 and T6 require 60 minutes after Monday’s earliest possible review finish. Only 30 remain. This is no fit even though the total-hours comparison looks sufficient.

Your starting prompt
Create three separate changed scenarios from the original source, never cumulative changes. A: replace only A's Tuesday window with 09:00–09:30. B: remove confirmed source availability for T1. C: add T6 as a prerequisite of T2. Keep all other owners, durations, windows, rules and deadline fixed. For A, derive the earliest possible T3 finish from T1 and T2, then compare the A work required after that handoff with A's remaining available time. Do not infer feasibility from total hours. For B, state the missing question without a guessed release or an impossibility claim. For C, show the cycle and require source correction. Report ready, blocked, no fit or invalid accurately. Propose any remedy only as a change requiring owner approval, never as an applied fix.

ORIGINAL COMPLETE SOURCE:
[paste]
Expect

Three independent scenario results: A no fit, B blocked and C invalid, each tied to its exact changed source.

Check

A: T1/T2 cannot let T3 finish before Monday 11:00; afterward T4/T6 need 60 A minutes but only 30 remain. B: ask when the approved T1 facts will be available. C: T2 → T3 → T4 → T6 → T2 is a cycle; T2 → T5 → T6 → T2 is another.

If it differs

If changes are combined, restart each case from the original source. Do not borrow B’s capacity, extend A’s window or guess release time. If no sound no-fit proof is supplied, leave search unverified. Any remedy is a proposed change needing separate owner approval.

06

Hand over a checked proposal with the right limits

Save the working plan beside the original source and blank worksheet. Real owners still need to confirm estimates, availability, authority and review scope. If review creates more than T4’s planned work, reschedule. The local arithmetic check does not prove real completion or an AI provider’s performance.

Your starting prompt
Prepare the final editable working proposal and a source-linked verification note. List every task once and reconcile totals, unused intervals, all handoffs and the deadline. Include each changed-case outcome and its exact reason. Label real owner approval pending until actually confirmed. Preserve the review-scope limit: if review creates work beyond the supplied revision duration, stop and reschedule with approved inputs. Separate arithmetic/parser checks from unperformed human usability, browser layout and AI-provider runs. Keep access unverified and time savings unmeasured. Do not claim delivery guarantees, create calendar events, contact anyone, publish, print or change source constraints. State that editing the Markdown does not automatically recalculate it.

SOURCE, CHECKED PROPOSAL AND CHANGE ANALYSIS:
[paste]
Expect

An editable final proposal and source-linked verification note including baseline checks, all changed-case outcomes and pending real approvals. Save and reopen them.

Check

Check the saved version still has all seven original tasks, the 240/330 work/capacity totals, Tuesday 10:30 finish, three distinct scenario states and R2’s revision limit. Editing Markdown does not recalculate these facts.

If it differs

If the saved file lost a row or limit, restore it in a new revision and repeat the relevant audit. Real owners must confirm estimates, windows, authority and review scope before use. More revision work needs new approved inputs and rescheduling; no calendar event, assignment, external message or delivery guarantee follows from this plan.

Optional: improve the result

Test one explicitly approved change at a time

If the owners want to explore a remedy, preserve the failed scenario and record the exact new permission. An extended window, different owner, new duration or later deadline is a new model. It needs a fresh schedule and owner confirmation; the example does not authorize any of those changes.

Advanced prompt
Compare the complete original project source with one explicitly approved revised constraint. Record who approved the change and which field changes; leave all other inputs intact only where they are confirmed unchanged. Validate release times and the dependency graph again. Recalculate person-by-person capacity, then construct and independently check every whole task, handoff and deadline. Show the old and new status with reasons and a readable revised proposal only if valid and feasible. A failed heuristic search is not proof of no fit. If real review scope or duration changed, require updated approved inputs. Do not silently revise another constraint, claim measured savings, create commitments or use a calendar.

ORIGINAL SOURCE:
[paste]

EXPLICIT APPROVED CHANGE AND CONFIRMED UNCHANGED INPUTS:
[paste]
Optional: use your own input

Propose a project from your own agreed inputs

Use fictional labels or permitted non-sensitive project data; keep private personnel details out. This route uses fixed task owners, indivisible uninterrupted tasks and one explicitly shared clock. Copy project-capacity-worksheet.md to my-project-worksheet.md and complete your own source fields. Start a new chat with the prompt below, check the inventory, then send:
“Validate MY ORIGINAL SOURCE AND WORKSHEET. Require unique known task IDs, fixed confirmed owners, positive durations, known prerequisite IDs, non-overlapping confirmed owner windows, full dates, deadline, grid definition and required release times. Detect cycles and show their actual edges. Separate blocked missing information from invalid contradictory input. Stop those scenarios with an exact question; do not guess a fact or remove an edge. ORIGINAL SOURCE AND WORKSHEET: [paste both].”
Compare validation with your source. Resolve holds with the responsible people before continuing; a valid source is not yet a checked schedule.
“For MY COMPLETE VALIDATED SOURCE, propose one schedule with each task once, original owner/duration, uninterrupted inside one owner window, starting on MY GRID after every prerequisite and required release and finishing by MY DEADLINE. No same-owner overlap; different owners may overlap only when dependencies permit. Show full dates/start/end and source-linked handoff checks. Do not split, reassign, shorten, extend windows or drop dependencies. A failed search is not proof of no fit; state what remains unverified. COMPLETE VALIDATED SOURCE INCLUDING GRID, WINDOWS, RELEASES AND DEADLINE: [paste].”
Save the proposed table as my-project-plan.md and reopen it. Check each original task is present, then send:
“Audit MY REOPENED SCHEDULE against MY ORIGINAL SOURCE. Independently calculate every duration, grid-aligned start, window containment, release and prerequisite endpoint, same-owner overlap and deadline. Sum each owner’s work and usable non-overlapping window minutes clipped to the deadline. List unused intervals, not just totals, and explain where dependent work needs capacity after a handoff. Preserve the source. ORIGINAL SOURCE AND REOPENED SCHEDULE: [paste].”
Recalculate the endpoints and totals yourself; correct, save/reopen and recheck a failed proposal. Define any practice scenario in a separate copy, with an explicit changed field and all unchanged inputs; it does not alter real commitments.
“Compare MY EXPLICIT SEPARATE SCENARIOS with MY ORIGINAL SOURCE. Apply each change independently, validate first and retain original owners, rules and scope except where explicitly changed for that scenario. For each show a checked fit, a sound no-fit proof or exhaustive-search result, a blocked missing question, or an invalid model/cycle. Do not call a failed heuristic no fit or guess missing releases. Record any real remedy as a proposal needing approval. ORIGINAL SOURCE, EACH LABELED SCENARIO AND WHETHER IT IS HYPOTHETICAL OR APPROVED: [paste; write none if no scenario is requested].”
Check each analysis against only its stated changes. Do not copy the example’s shorter window, missing T1 release or T2/T6 edge into your project. Then send:
“Prepare MY FINAL EDITABLE PROPOSAL AND VERIFICATION NOTE from MY ORIGINAL SOURCE, REOPENED CHECKED PLAN, INDEPENDENT CHECKS AND SCENARIO ANALYSIS. Reconcile every task, owner, handoff, unused interval and deadline. Keep unresolved facts and actual owner-approval status visible. If review scope exceeds the supplied revision work, hold and require new approved inputs. No commitments, calendar actions, messages, printing or publication; no delivery guarantee or measured savings. FULL SOURCE, CHECKED PLAN, CHECK RESULTS AND SCENARIO ANALYSIS: [paste all].”
Save the complete final plan/note in my-project-plan.md and reopen it against the source. Correct new revisions rather than overwriting evidence of failures. The original advanced exercise is sample-scoped; an own-input remedy needs the full original source, one explicitly approved revised constraint, its approval source and confirmation of unchanged inputs. Revalidate and recheck the whole proposal, then obtain the relevant owners’ confirmation before real use.

Your own-input prompt
Help me prepare a small-project proposal from supplied inputs only. First organize my source without scheduling: purpose and acceptance scope, excluded work, stable task IDs, fixed owners, positive indivisible durations, prerequisites, required source releases, confirmed dated work windows, a common clock, exact deadline, start-grid interval and origin, and the limited review/revision scope. Record input sources and actual confirmation/approval states. Keep the original unchanged. Treat missing as unknown; confirmed no prerequisite differs from an unanswered field. Stop for my review. Later we will validate the graph, propose whole-task placements, audit a saved plan and separately analyze explicit changes. Do not change owners, durations, dependencies, windows or scope; create no commitments, events or external messages. A mathematical fit does not guarantee delivery.

MY COMPLETE PROJECT SOURCE
[Give project/version/purpose/exclusions; each task’s ID, owner, duration, prerequisites and any required dated release; each owner’s confirmed start/end windows with full dates on the common clock; deadline; exact allowed start grid including origin; whether ending exactly at a window/deadline is allowed; indivisibility/no-overlap rules; review/revision scope; source references and who can resolve or approve changes. Flag any unknown or unconfirmed input. If clocks differ, resolve a common-clock source separately rather than assuming offsets.]

Check your own result

  • Every task retains your actual ID, owner, indivisible duration, dependencies and required releases. No sample task or date is imported.
  • Every start follows your grid and every entire task fits one confirmed owner window, after all prerequisites, without same-owner overlap and within the deadline.
  • Capacity is checked by owner and time after handoffs; spare time before a prerequisite or another owner’s time cannot cover the work.
  • Unknown inputs are blocked, contradictions invalid, and no fit needs a sound proof or exhaustive search. Failure to find a plan is labeled unverified.
  • Scenarios remain separate from the original and each other. Any real constraint or review-scope change needs approved inputs and a fresh full check.
  • The saved proposal matches the checked source and preserves actual owner-approval states. Text edits do not recalculate; no delivery, calendar action or real assignment is established.
Show, then try

See the shape of the result.

This input is synthetic. The output is a written illustration of the intended result, not a verified AI-tool run.

The starting point

Synthetic input
# Welcome-pack project: complete source exercise

Original synthetic fixture, project-capacity-v1. The club and adults below are fictional. This file contains the supplied inputs, not a solved schedule. Keep it unchanged beside any proposed plan.

## P1: Purpose and deadline

Prepare a fictional adult club's four-page welcome-pack draft for internal review. Printing, publication and invitations are outside the project. The deadline is Tuesday 20 October 2026 at 10:30. All times use the same supplied local clock; no time-zone conversion is needed or authorized.

## W1: Editor A's agreed windows

- Monday 19 October 2026, 09:00–11:00
- Tuesday 20 October 2026, 09:00–10:00

## W2: Reviewer B's agreed windows

- Monday 19 October 2026, 10:00–11:00
- Tuesday 20 October 2026, 09:00–10:30

Both fictional people have explicitly agreed to the listed tasks and only these work windows. Real people's agreement, estimates and availability must be confirmed separately.

## R1: Scheduling rules

Tasks are indivisible and run without interruption. Each task uses only its assigned person. Starts must be on 30-minute boundaries, such as 09:00 or 09:30. No person may perform two tasks at once. Every prerequisite must finish no later than the dependent task starts. Each complete task must fit inside one of its owner's windows and finish no later than the project deadline. Different owners may work in parallel when prerequisites permit it. These durations are supplied planning assumptions, not measured promises.

## T1–T7: Task source ledger

| ID | Task | Owner | Minutes | Prerequisites | Additional input |
| --- | --- | --- | ---: | --- | --- |
| T1 | Assemble the already approved source facts | A | 30 | None | Source available Monday 19 October 2026 at 09:00 |
| T2 | Draft the four-page pack | A | 60 | T1 | None |
| T3 | Review factual wording | B | 30 | T2 | None |
| T4 | Apply the review notes | A | 30 | T3 | See R2 |
| T5 | Check the supplied links | B | 30 | T2 | None |
| T6 | Assemble the review copy | A | 30 | T4 and T5 | None |
| T7 | Check the assembled copy | B | 30 | T6 | None |

## R2: Review scope and authority

The fixture assumes T3 produces only work covered by T4's supplied duration. If a real review changes scope or duration, reschedule. Do not invent unlimited revision capacity. Do not move a task to another person, split it, extend a window, shorten an estimate or remove a prerequisite without approval. This exercise proposes a schedule; it does not assign real work, promise delivery or authorize calendar actions.

## C1: Changed case A

Replace A's Tuesday 20 October window with 09:00–09:30. Everything else stays fixed. Decide whether all seven complete tasks can still meet the deadline under R1 and R2. Explain the limiting dependency or window if there is no fit; do not judge feasibility only by a total-hours comparison.

## C2: Changed case B

The source facts for T1 have no confirmed availability. Their release time is unknown. Everything else stays fixed. Do not invent a release time or treat missing availability as an early release.

## C3: Changed case C

T2 is said to depend on T6 as well as T1. Everything else stays fixed. Do not silently remove a dependency to produce a schedule.

## O1: Requested output and decision boundary

Create a readable two-day proposal, a source-linked dependency check and owner-by-owner capacity accounting. Include every task exactly once with the supplied owner and duration. State the outcome of the baseline and each independent changed case; identify unresolved information or invalid inputs before offering an executable-looking plan. Preserve the original inputs when comparing a changed case.

Before using a real version, the owners must confirm estimates, availability, authority and the review-scope limit. No live calendar action, external communication, printing or publication is part of the exercise. A mathematical fit does not establish human acceptance or a delivery guarantee.

Copies text only. For image or file tasks, use the source files named in the steps too.

Download source .txt

The intended result

Illustrative output
# Two-day welcome-pack work plan

Synthetic proposal · project-capacity-v1 · all times on the supplied local clock

Status: ready as a mathematical proposal. Finish: Tuesday 20 October 2026, 10:30, exactly at the deadline. These are not real commitments. Owners still need to approve any real version, including estimates, availability, authority and review scope.

[Complete unchanged source](project-capacity-source.md) · [Blank worksheet](project-capacity-worksheet.md) · [Dependency checks and changed cases](project-capacity-reasoning.md)

## Work in this order

| Day (2026) | Work window | Owner | Task ID | Work to do | Release check before starting |
| --- | --- | --- | --- | --- | --- |
| Mon 19 Oct | 09:00–09:30 | A | T1 | Assemble the already approved source facts | Source available at 09:00 |
| Mon 19 Oct | 09:30–10:30 | A | T2 | Draft the four-page pack | T1 finished at 09:30 |
| Mon 19 Oct | 10:30–11:00 | B | T3 | Review factual wording | T2 finished at 10:30 |
| Tue 20 Oct | 09:00–09:30 | A | T4 | Apply the review notes | T3 finished Monday at 11:00 |
| Tue 20 Oct | 09:00–09:30 | B | T5 | Check the supplied links | T2 finished Monday at 10:30 |
| Tue 20 Oct | 09:30–10:00 | A | T6 | Assemble the review copy | T4 and T5 both finished at 09:30 |
| Tue 20 Oct | 10:00–10:30 | B | T7 | Check the assembled copy | T6 finished at 10:00 |

Source references: task IDs refer to the source's T1–T7 ledger; A's windows are W1, B's W2; rules are R1. T4 and T5 run in parallel because they have different owners. Every task is one uninterrupted block with its original owner and duration. The final deliverable is a draft for internal review only: no printing, publication or invitation.

## Capacity check

| Owner | Work (min) | Available (min) | Unallocated (min) |
| --- | ---: | ---: | ---: |
| A | 150 | 180 | 30 |
| B | 90 | 150 | 60 |
| Total | 240 | 330 | 90 |

Unused windows: A Monday 10:30–11:00; B Monday 10:00–10:30 and Tuesday 09:30–10:00. These are not interchangeable revision buffers. A cannot use Monday's spare half hour for T4 before the review finishes at 11:00. There is no time between the planned final check and the deadline.

## If an input changes, stop and recheck

- Changed A (C1): A's Tuesday window is 09:00–09:30. Status: no fit. A still has 150 total available minutes, but T4 and T6 need 60 minutes after Monday's review and only 30 remain. Do not keep the old schedule or borrow B's time.
- Changed B (C2): source availability is unconfirmed. Status: blocked. Ask when the approved source facts will be available; do not invent an early release or claim impossibility.
- Changed C (C3): T2 also depends on T6. Status: invalid. The dependency cycle must be resolved by the source owner before scheduling.
- Review scope (R2): if T3 creates work beyond T4's 30-minute assumption, hold and reschedule with approved inputs. Do not assume extra revisions fit.

## Use this as a working proposal

Copy the [blank worksheet](project-capacity-worksheet.md) for new inputs. Keep this example and its source unchanged. Do not split work, change owners, extend windows, reduce estimates or delete dependencies without approval. The Markdown is editable but does not recalculate. Any edit needs a fresh dependency, overlap, capacity and deadline check before owner confirmation.

Owner confirmation: pending for any real use. Calendar actions: none. Time savings: unmeasured. The supplied synthetic arithmetic was checked locally; human acceptance, browser layout and an AI-provider workflow were not tested.
Download result .txt
You’re the final check

Check the worked example.

These checks use the worked example and its particular facts. With your own material, check your actual names, numbers, sources and rules; do not reuse the sample’s values as the answer.

Unsaved checks stay in this tab and reset when you reload. If you choose Save guide, its current example checkmarks are kept in this browser when storage is available.

A few things to watch for.

  • Calling a plan feasible because total available minutes exceed total work, without checking whose time is available after each handoff.
  • Treating spare time before the factual review as a revision buffer after it.
  • Starting assembly after only one of its two prerequisites, or overlapping two tasks owned by A.
  • Splitting a task, reassigning work, shortening an estimate or extending a window to hide a failed fit.
  • Calling unknown source availability impossible, or treating a dependency cycle as permission to delete an edge.
  • Keeping the baseline plan after a window or review scope changes.
  • Assuming an editable Markdown schedule recalculates automatically, or describing an automated check as a human acceptance test.

What has been checked?

Documentation
No dated source review recorded.
Included files
Scoped checks passed on 2026-10-14. Fixture checks; File parsing. See scope below.
AI workflow
Not run in a recorded consumer-AI workflow.
Time savings
Time savings not measured
Read the scope and evidence

project-capacity-working-plan.md

2026-10-14 · semantic fixture · passed

Literal schedule rows, totals and state labels reconciled with the independent enumeration and source; relative links resolved. This is text/fixture checking, not a human readability or browser layout review.

  • Seven exact schedule rows retained
  • A 150/180 and B 90/150 minute accounting
  • Changed-A no-fit, changed-B blocked and changed-C invalid labels

Environment: Python 3.12.14 standard library on local Linux; read-only check-fixture.py, independent topological and Cartesian enumeration, exact integer minutes and in-memory negative cases. No network, browser, consumer AI, calendar or real project execution.

SHA-256: 61a61b10863770818d4569af23e22f0fa6005f793b914529f81113aa9ae0ba4b

project-capacity-worksheet.md

2026-10-14 · parser · passed

Required blank source, task, window, approval and status fields and relative links checked as text. No completed human worksheet or rendered usability check.

  • Blank owner, duration, prerequisites and source fields
  • Distinct ready/blocked/no-fit/invalid meanings
  • Review-scope and owner-confirmation gates

Environment: Python 3.12.14 standard library on local Linux; read-only check-fixture.py, independent topological and Cartesian enumeration, exact integer minutes and in-memory negative cases. No network, browser, consumer AI, calendar or real project execution.

SHA-256: 08ca6ed7683c058b3a1934900814977a3f475db0f7233699eb3234aa67a7d0dd

project-capacity-source.md

2026-10-14 · semantic fixture · passed

Complete synthetic source text checked against separately structured inputs, exact task tuples, windows, release, deadline, rules and changes; frozen before answer authoring. No external factual verification is claimed.

  • Seven task rows and original owners/durations
  • Four exact work windows and source release
  • All three independent changes and limited review scope

Environment: Python 3.12.14 standard library on local Linux; read-only check-fixture.py, independent topological and Cartesian enumeration, exact integer minutes and in-memory negative cases. No network, browser, consumer AI, calendar or real project execution.

SHA-256: 9273b5fcc3a199ff56092a67b6c8180b44614edc81d64dd9a3e31979198ab217

project-capacity-source.json

2026-10-14 · semantic fixture · passed

JSON parsed and canonical task/window/rule inputs checked; topological enumeration compared with an independent literal Cartesian oracle. Missing source and cyclic input classified before scheduling.

  • One baseline schedule from 108000 Cartesian assignments
  • Zero changed-A schedules from 46875 assignments
  • Missing release blocked; cycle invalid

Environment: Python 3.12.14 standard library on local Linux; read-only check-fixture.py, independent topological and Cartesian enumeration, exact integer minutes and in-memory negative cases. No network, browser, consumer AI, calendar or real project execution.

SHA-256: 0b2ce502633d8aec84c11d662a6b7a48f19b748905e2dfb7524f999e6c57557d

project-capacity-reasoning.md

2026-10-14 · semantic fixture · passed

Source-linked task rows and exact result statements checked as text against the computed fixture. The no-fit argument is tied to earliest review completion and remaining A time; no human proof review is claimed.

  • 240 work minutes and 330 available minutes
  • 60 post-review A minutes versus 30 changed capacity
  • Cycle and unperformed-review labels retained

Environment: Python 3.12.14 standard library on local Linux; read-only check-fixture.py, independent topological and Cartesian enumeration, exact integer minutes and in-memory negative cases. No network, browser, consumer AI, calendar or real project execution.

SHA-256: 22784c29c6e82f442fa06885164d7b0a04ce16115c62f4e56dd11af85ff6dcc5

project-capacity-result.json

2026-10-14 · semantic fixture · passed

Source-hashed static answer reconciled to independent enumeration, owner capacity and distinct outcome states; schedule and answer mutations rejected. This establishes only the synthetic model.

  • All seven exact scheduled tasks pass timing constraints
  • 28 negative schedule/input/answer cases rejected
  • No calendar actions or real commitments; savings unmeasured

Environment: Python 3.12.14 standard library on local Linux; read-only check-fixture.py, independent topological and Cartesian enumeration, exact integer minutes and in-memory negative cases. No network, browser, consumer AI, calendar or real project execution.

SHA-256: bc40140565aeb26bcbbc3d08bf6687b3c06cfb0f6c2f87bfc3f4a04eca9a255e

project-capacity-diagram-v1.png

2026-10-14 · semantic fixture · passed

Direct editorial inspection of the actual accepted raster and byte identity to that reviewed file, with supplied synthetic values reconciled to fresh local arithmetic. This check does not establish integrated browser rendering, user accessibility, AI performance or real-world plan reliability.

  • Accepted raster retained byte-for-byte; intrinsic dimensions 780 × 3254; actual image opened and inspected.
  • Fresh exhaustive enumeration: 108000 baseline assignments give exactly the supplied one schedule; 46875 changed-A assignments give zero.
  • All seven task owners, durations, dependencies and original windows retained; T7 ends Tuesday 10:30 exactly at the deadline.
  • A uses 150 of 180 minutes; B uses 90 of 150; total 240 of 330. B Monday unused availability is 10:00–10:30; before 10:00 is unavailable.
  • C1 no fit, C2 missing-release blocked and C3 cyclic-input invalid remain separate; real owner confirmation, R2 review scope and no-calendar-action limits retained.

Environment: Local Linux; arithmetic and exhaustive synthetic schedule enumeration, static SVG text/structure and SHA-256 checks, PNG verification, and direct visual inspection of the accepted PNG. No browser, consumer AI, real booking or physical trial.

SHA-256: 42598f186bdf8831b4b62fb718914e7c11fb30a9e6b478fabd98c48890604fc4

project-capacity-diagram-v1.svg

2026-10-14 · semantic fixture · passed

Static SVG elements/attributes and visible text inspected; exact accepted bytes retained and supplied synthetic values reconciled to local arithmetic. This is a static fixture/source check, not a browser, physical trial or consumer-AI execution.

  • Accepted SVG retained byte-for-byte; 390 × 1627 viewBox; static allowlisted elements and no external references, events or active content.
  • Fresh exhaustive enumeration: 108000 baseline assignments give exactly the supplied one schedule; 46875 changed-A assignments give zero.
  • All seven task owners, durations, dependencies and original windows retained; T7 ends Tuesday 10:30 exactly at the deadline.
  • A uses 150 of 180 minutes; B uses 90 of 150; total 240 of 330. B Monday unused availability is 10:00–10:30; before 10:00 is unavailable.
  • C1 no fit, C2 missing-release blocked and C3 cyclic-input invalid remain separate; real owner confirmation, R2 review scope and no-calendar-action limits retained.

Environment: Local Linux; arithmetic and exhaustive synthetic schedule enumeration, static SVG text/structure and SHA-256 checks, PNG verification, and direct visual inspection of the accepted PNG. No browser, consumer AI, real booking or physical trial.

SHA-256: 7d37e68b8be41db7607c99de1c4a5e1ac29922250ea240646d208f2d2abec6b1

project-capacity-diagram-v1.md

2026-10-14 · semantic fixture · passed

Text equivalent preserves every substantive source line; only the source-hash line, internal revision footnote and heading revision suffix were removed. Supplied synthetic values and limits reconciled to local arithmetic; no live execution or plan-reliability claim.

  • Exact three-part text delta recorded; all substantive lines, constraints, unknowns and limits retained.
  • Fresh exhaustive enumeration: 108000 baseline assignments give exactly the supplied one schedule; 46875 changed-A assignments give zero.
  • All seven task owners, durations, dependencies and original windows retained; T7 ends Tuesday 10:30 exactly at the deadline.
  • A uses 150 of 180 minutes; B uses 90 of 150; total 240 of 330. B Monday unused availability is 10:00–10:30; before 10:00 is unavailable.
  • C1 no fit, C2 missing-release blocked and C3 cyclic-input invalid remain separate; real owner confirmation, R2 review scope and no-calendar-action limits retained.

Environment: Local Linux; arithmetic and exhaustive synthetic schedule enumeration, static SVG text/structure and SHA-256 checks, PNG verification, and direct visual inspection of the accepted PNG. No browser, consumer AI, real booking or physical trial.

SHA-256: 2b94062407d39c73074cc817a5dfbe9957ee666b965f9e54684409134f6c3884

Copy these instructions

Your browser blocked automatic copying. Select the text below and copy it.