CPM Engine

Each commit in a GitHub repo becomes an activity. Each parent→child relationship becomes a dependency. The engine runs a topological sort, forward pass, and backward pass over that graph — the same three passes any CPM textbook teaches for a construction schedule — and reports which commits sat on the critical chain and which branches had slack before they needed to merge.

Merge commits create fan-in edges, so parallel branches surface as parallel paths in the network diagram, not a flattened line.

Six sessions, three months elapsed, in the order they actually happened — not a plan written in advance.

The GitHub importer was the last feature, and it's also what surfaced the project's actual limit. CPM is a prospective planning method — it needs someone to estimate durations before work starts, so a schedule can be optimized against those estimates. Commit history is unavoidably retrospective: it only records what already happened. No amount of API polish closes that gap without a person supplying estimates by hand, which isn't what a GitHub importer is for.

The alternative was extending the data model — issues, PRs, and manual duration input as a second, prospective input path alongside the commit importer. That would have made the tool actually do PM planning again. It was scoped out on purpose: the entity model (Project → Activity → ActivityDependency) and the mapper were built around one shape of input, commit graphs, and bending that into two incompatible planning modes was a rewrite, not a feature.

"This mismatch was identified during development. The project was closed out as a working portfolio artifact rather than extended into something it couldn't be." — README, Status

Closing a project on purpose is a decision, not a stall. The engine and the importer both work end-to-end against real repos; the thing that doesn't exist is a feature the tool was never actually positioned to have.

ES / EF / LS / LF / slack are computed on request, never persisted — CriticalPathService is a pure function over activities and dependencies, so re-running it against edited data can't drift from stored numbers because there are none to drift.

// GitHubActivityMapper — duration is elapsed time, not effort
$latestParentDate = max(array_map(fn($sha) => $dates[$sha], $inWindowParents));
$seconds  = $dates[$commit['sha']]->getTimestamp() - $latestParentDate->getTimestamp();
$duration = (float) max(0, (int) round($seconds / 3600));

A commit's "duration" is the rounded hours since its latest in-window parent — the same elapsed-vs-effort gap the build log above shows by hand: a 43-day gap between sessions isn't 43 days of work, and neither is a commit dated 43 days after its parent.

Documented in the README rather than discovered by a user — these are the edges of v0, not bugs:

• No pagination — only the most recent 100 commits per import (GitHub's default page size)
• No URL normalization — .git suffix and trailing-slash variants of the same repo count as separate projects
• Re-import replaces in place — same URL overwrites that project's activities under the same project_id, rather than versioning
• No route-level test for the import endpoint — the mapper has unit tests; controller persistence was verified by hand against three real repos