Development Lifecycle
hashd orchestrates four delivery phases from requirements to merged code, keeping humans and agents aligned from scope definition through final integration.
Phase Overview
Each phase has clear handoffs and traceable outputs so execution remains deterministic while still allowing targeted human control when it matters.
Phase 1
Planning
Planning starts with discovery from real requirements, not assumptions. hashd analyzes REQS.md, scans the codebase for relevant architecture and touchpoints,
then produces a ranked set of implementation stories.
Each selected story is broken into scoped, reviewable units with explicit acceptance criteria. The output is a clear plan humans can approve quickly and agents can execute deterministically in Phase 2.
Terminal
$ wf plan
Analyzing REQS.md and repository context...
Scanning modules, interfaces, and integration points...
Generated 4 story candidates:
1. STORY-1042 Auth session refresh flow
2. STORY-1043 Workspace onboarding states
Acceptance criteria drafted for each story.
$ wf plan new 1Phase 2
Implementation
Execution runs as a micro-commit loop: implement, test, review, gate. hashd selects one scoped commit at a time, then agents move through each stage in order so changes stay small, inspectable, and reversible.
The implementation agent writes code, tests validate behavior, and AI review checks quality before human or gatekeeper policy decides whether to proceed. No next commit starts until the current commit passes its checks.
If test or review fails, the same commit re-enters the cycle with feedback until approved. This iterative loop keeps risk localized per commit instead of deferring validation to the end of a large branch.
Micro-Commit Stage Loop
Implement Test Review Gate
Gatekeeper mode auto-continues when tests pass and review approves; otherwise it requests changes and loops on the same commit.
Terminal
$ wf run STORY-1043 --loop --gatekeeper
Loading workstream and selecting next micro-commit...
[commit 2/5] IMPLEMENT agent wrote changes in onboarding flow
[commit 2/5] TEST pass (27/27)
[commit 2/5] REVIEW approve (confidence 0.91)
[commit 2/5] GATE auto-approve and continue
[commit 3/5] IMPLEMENT add empty-state handling
[commit 3/5] TEST fail (1)
Looping commit 3/5 with test feedback...
[commit 3/5] IMPLEMENT patched state transition guard
[commit 3/5] TEST pass (27/27)
[commit 3/5] REVIEW approve
[commit 3/5] GATE auto-approve and continuePhase 3
Final Review
After all micro-commits pass their local loops, hashd runs a final branch review over the complete diff. This step evaluates cross-commit behavior, integration edges, and system-wide quality that may not be visible when reviewing each commit in isolation.
The reviewer returns either APPROVE or CONCERNS. Concern flags are explicit and actionable, so humans can decide whether to proceed, request fixes, or loop back with one targeted follow-up commit.
This is the branch-level quality gate before merge: per-commit gates protect local correctness, while final review protects global coherence.
Final Branch Gate
Review Full Diff Flag Concerns Human Decision Ready to Merge
Terminal
$ wf review STORY-1043
Running final review on full branch diff...
Verdict: CONCERNS
- Potential race condition in workspace hydration path
- Missing rollback note for migration edge case
State: awaiting_final_decision
$ wf approve STORY-1043
Final gate approved by human; proceed to merge.Phase 4
Merge
Merge begins once a branch reaches ready_to_merge. Teams can merge locally or open a GitHub PR, but both paths preserve the same safety model: deterministic state transitions, tracked approvals, and conflict handling with bounded retries.
For PR mode, wf pr create publishes the branch and moves the workstream into external review, then wf merge
performs auto-rebase when main has moved. If rebase conflicts appear, hashd attempts automated conflict resolution before escalating to human review.
After merge, hashd finalizes documentation and closes the loop: update SPEC from merged implementation context, clean WIP blocks in REQS on main, archive the workstream, and remove the worktree as post-merge cleanup.
Merge Pipeline
Create PR External Review Merge + Rebase Docs + Cleanup
Terminal
$ wf pr create STORY-1043
Creating pull request from story/1043-workspace-onboarding...
PR #184 opened: github.com/codr1/hashd/pull/184
State: pr_open
$ wf merge STORY-1043 --confirm --ai-resolve
Main moved ahead, attempting auto-rebase...
Conflict resolved automatically (2 files, strategy: minimal-diff)
Merge complete on main
Updating SPEC.md from merged diff...
Cleaning REQS.md WIP sections on main...
Archived STORY-1043 and removed worktree.