fix: include cadence-less projects in project_progress#19
Conversation
project_progress previously required expected_cadence to be set for a project to appear in projects[], hiding in_progress/planned projects that simply hadn't had a cadence assigned yet. A cadence-less project now appears with expected_cadence "" and stalled always false — project.Stalled already treated an unrecognised/empty cadence as no threshold to exceed, so only the SQL candidate gate and its doc comments needed to change.
🤖 Augment PR SummarySummary: This PR fixes Changes:
Technical Notes: Cadence-less projects should still appear but never be marked 🤖 Was this summary useful? React with 👍 or 👎 |
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
| noCadence, ok := byProjectSlug["no-cadence"] | ||
| if !ok { | ||
| t.Errorf("no-cadence project missing from projects[], want included (cadence-less, not excluded)") | ||
| } else if noCadence.Stalled { |
There was a problem hiding this comment.
This test doesn’t currently exercise the “cadence-less but has an open next action” case: the no-cadence project is inserted without any todos/milestones so open_next_action will likely be false and stalled will be false regardless of cadence. As written, it may not catch a regression where cadence-less projects become stalled when they do have an open next action.
Severity: medium
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
… cadence-miss path The no-cadence candidate-filter test's stalled=false assertion could pass vacuously two ways: the seeded project had no open next action (Stalled short-circuits on !openNextAction before ever consulting cadence), and its own INSERT ran without setting koopa.actor, so the audit trigger's 'human' fallback gave it a last_human_activity_at of "just now" (Stalled's now.Sub(lastHuman) > threshold branch is never true for a few-millisecond gap regardless of the threshold). Neither gap was hit by cadenceDays[""] resolving correctly. Give the project an open todo (via a non-human actor, so the todo's own creation event doesn't add human activity either) and seed the project itself under a non-human actor so it has no human activity at all — lastHuman stays nil, which is the one branch where a broken cadenceDays[""] lookup (ok=true) would flip the result to stalled=true. Verified by temporarily mutating cadenceDays to accept "" and confirming the test fails, then reverting. Flagged by Augment's automated PR review.
|
Addressed: the |
1 participant
Summary
project_progress'sProjectMomentumquery previously excluded anyin_progress/plannedproject withoutexpected_cadenceset, hiding real projects from the owner's momentum view.stalled(no threshold to exceed without a cadence) —project.Stalledalready handled this correctly for empty/unrecognised cadence, so only the SQL candidate gate and its doc comments needed to change.Changes
internal/project/query.sql— removedAND p.expected_cadence IS NOT NULLfromProjectMomentuminternal/db/query.sql.go— regenerated viasqlc generateinternal/project/progress.go— updated doc comments (Momentum,deref,ProjectMomentumstruct)internal/mcp/ops/catalog.go— updatedproject_progresstool descriptioninternal/mcp/integration_test.go—TestIntegration_ProjectProgress_CandidateFilternow asserts a cadence-less project IS included withstalled=false, instead of asserting exclusionTest Plan
go build ./...,go vet ./...,golangci-lint run ./...— 0 issuesgo test ./...— pass-tags=integration, real PostgreSQL via testcontainers) forinternal/mcpandinternal/project— pass, including the updated candidate-filter testexpected_cadenceis always non-NULL for aprojects[]row