easd-plan

Plan an accepted EASD specification

Repository contract

Read .evoflux/easd/config.json and its rules_file before phase work. Treat the injected EASD context as the authoritative current Run; when the owning runtime is accessible, corroborate it under runtime_directory. An isolated worktree intentionally has no checkout-local runtime copy. Resolve the accepted revision through the Run's common specs/ catalogue index and confirm its hash matches the Run snapshot. Read affected current-state knowledge without relocating existing project docs. Repository documents are the shared source of truth. Stop on a missing tracked contract, stale hash, generation conflict, or unavailable injected runtime; never reconstruct authority from chat memory or a stale database-only projection. If the accepted Spec selected direct, stop: Plan is intentionally skipped and this Skill has no authority.

Build the execution map from the exact accepted specification hash. Planning does not authorize implementation and must not weaken the accepted contract.

State gate

Re-read the current run and accepted revision before planning. Stop if there is no accepted hash, if the hash differs from the one supplied to this turn, or if the run is terminal. accepted waits for the user's Run plan action; planning permits one typed plan submission; plan_review is human review and cannot be overwritten by the agent; planned belongs to implementation. If the accepted revision changes, discard the stale plan and compile from the new hash.

Compile the work

1. Confirm the run ID, accepted spec hash, status, risk tier, ACs, impact targets, constraints, and evidence policies from injected EASD context.
2. Map every required AC to an implementation owner and concrete files/modules, dependencies, and expected evidence. Add explicit verification missions that collectively own every accepted Proof command; a command without a Verify owner is a plan gap, not an implementation detail.
3. Put shared contracts before dependent layers. Record the exact interface each slice consumes and produces. Split parallel missions by disjoint ownership; name one integration owner wherever overlap is necessary.
4. Add a separate review mission for every run. Apply independence in proportion to risk: cross-layer and critical review must be owned by someone who did not author the affected change, and its task should explicitly request EASD independent review so the repository's easd-review Skill can be selected.
5. Include negative paths, migration/compatibility, security, observability, documentation, and rollback work only where the accepted specification or affected boundary requires them.
6. Order slices so each ends in a behavior that can be tested and reviewed independently. For observable changes and regressions, plan the failing test or other baseline observation before the implementation that makes it pass.
7. Run an implementability check: a developer or specialist must be able to execute every slice without inventing product behavior, interface ownership, setup, or verification. Return real gaps to specification/design instead of hiding them in task prose.