Module devtask 

The devtask module: an issue and a milestone read as executable development scopes.

Why this is a module and not two more plan.* capabilities

Every capability is composed into exactly one Rust module, and a module’s id is the namespace of everything in it, so plan.task would have to live inside builtin/plan.rs. It does not belong there: plan is the projection of crate::plan, which is held to byte equality with lib/project.awk by test/cases/99_plan_capabilities.sh, and a capability that joins the plan to git and to the session records has no counterpart in the awk to be equal to. Keeping them apart keeps that equality checkable.

What it must not be is a second project model, and it is not:

• the records are the canonical ones, read through the index like every other object;
• the status, wave, dependents, edges and findings are crate::plan’s, unchanged — the_status_never_disagrees_with_the_plan is the assertion;
• the branches and commits are worktree::trace’s, through the same Tracer trace.issue uses;
• the readiness vocabulary is a projection of the canonical statuses and refines three of them without replacing any — crate::devtask::readiness states which and why;
• the external projection stays scripts/github-sync’s. Nothing here writes, and nothing here restates its reconciliation vocabulary.

Why the milestone graph does not touch git

devtask.milestone is a pure function of the index, and deliberately: a graph whose ordering depended on git for-each-ref would be a graph that differs between a full clone and a shallow one, and this repository has already been bitten by a derivation that was machine-dependent. devtask.issue consults git because a single issue’s branches are the question being asked; the graph does not, because they are not.

Structs

DevMilestoneInput

Which milestone to read as a dependency graph.

DevTaskInput

Which issue to read as a development task.

Functions

module

The devtask module: the canonical development task, composed from derivations that already exist.