Flow Status Summary

Use this status memo when evaluating flow as a workflow contract for engineers and operators.

flow is moving in the right direction. Its core shape is sound: it constrains implementation drift through task, spec, and plan discipline; it captures lifecycle evidence across the task path; and it reserves hard acceptance blocking mainly for closeout or explicitly opted-in gates.

The important distinction is that plan-before-implementation is not an overblocking delivery gate. It is a local reliability guardrail for long-running LLM implementation. Models can lose focus, forget the current task boundary, or continue from stale intent in a long session. Requiring a recorded plan before tracked implementation gives the agent a stable task map before it starts changing source files. That is different from acceptance governance, which is aimed at human awareness and remote delivery readiness.

Public Workflow Surfaces

wap-flow start binds the working session to one task authority and one canonical spec. For GitHub-backed work, the branch must match the task issue. For local-private work, the local task record under flow/state/tasks/ is authoritative. The public contract is task-first: GitHub issue data is optional context, not the only valid authority model.

wap-flow plan record is the intentional transition from pending implementation intent to ready implementation intent. It records the summary and steps in the authoritative task path and syncs the local active-task snapshot. This is the point where the agent and operator agree on what is being changed, why, and how the result will be validated.

wap-flow check is the normal local guardrail surface. It validates active task state, branch binding, spec metadata, task size, recorded-plan status, and validation evidence. The policy is deliberately tiered: a pending plan on a clean tree is a warning, while tracked implementation edits with a pending plan are blocking. Missing validation evidence is also a warning before handoff, not a premature implementation blocker.

The installed hooks under flow/hooks/ repeat that contract only after wap-flow install-hooks has configured them. pre-commit runs wap-flow check. pre-push runs wap-flow check for normal implementation pushes and wap-flow doctor --strict for default-branch maintenance pushes or deletion-only ref cleanup. Hook-time acceptance checks are separate and depend on the active acceptance profile.

wap-flow complete --evidence <text> records implementation validation evidence. It means the implementation has recorded what passed. It does not mean the task is accepted, finalized, merged, or closed. Keeping complete, accepted, finalized, and closed separate is one of the strongest parts of the current public model.

wap-flow inspect issue is the read-only cockpit. The command name is retained for compatibility, but the payload is task-first. It aggregates task state, memory wake-up context, acceptance summary, PR summary, worktree status, and review-context status without becoming a new authority or a new blocker taxonomy.

wap-flow memory wake-up is the advisory context surface. It renders bounded, task-scoped knowledge from current authoritative state plus task-linked memory. Lifecycle commands also write advisory snapshots into memory, so long-running work has a durable awareness trail without making memory the source of truth.

wap-flow accept is the acceptance and closeout surface. It works for both GitHub-backed and local-private authority. Local-private tasks can finalize locally without GitHub publication. GitHub-backed tasks can use PR-bound profiles when remote review or issue closure is part of the delivery path.

wap-flow pr remains the GitHub-backed PR lifecycle surface. It coordinates PR state, merge readiness, and reconciliation, but it does not replace accept as the owner of acceptance truth. In particular, pr reconcile --strict must not treat a merged PR as permission to bypass missing acceptance, unfinished remote review, stale target checks, or unpublished blocking findings.

wap-flow doctor is the repo-pack and source health surface. Its diagnostic codes and repair-order output are public operator contract. It is the right place for repo-pack integrity, tracked hook health, spec-pack health, acceptance config validity, and source-repo readiness checks.

Guardrails, Awareness, And Gates

Planning guardrails prevent LLM drift before tracked implementation. The plan-before-edit rule is therefore worth keeping. It constrains the model’s working set to the task authority, canonical spec, likely files, validation commands, risks, and rollback points. It is a local cognition and scope control, not a general-purpose block on agent autonomy.

Awareness surfaces are intentionally broad. start, complete, acceptance lifecycle commands, PR lifecycle commands, memory snapshots, wake-up rendering, accept status, pr status, and inspect issue all help a human operator understand what happened and what remains to be done. The best current phrasing is: capture widely, summarize clearly, and keep the source of truth owned by the proper domain.

Delivery gates are intentionally narrower. The default acceptance posture is closeout-only blocking. accept finalize, strict acceptance checks, unfinished remote review states, stale PR head checks, and strict PR reconciliation are the places where hard stop behavior belongs. Commit and push acceptance gates exist, but they are not the default policy.

Current Policy Posture

The repository default in flow/acceptance.yml is manual-first and closeout-only:

• review_enforcement.commit: disabled
• review_enforcement.push: disabled
• review_enforcement.closeout: blocking

That default matches the public contracts in flow/specs/flow-acceptance-config-contract.md, flow/specs/flow-acceptance-lifecycle-contract.md, and flow/specs/flow-cli-contract.md. Disabled commit and push gates are true no-ops at those hook points: they must not evaluate acceptance freshness and must not emit gate-specific warnings or blockers.

Commit and push acceptance enforcement are still available for compatible local non-PR profiles that explicitly opt in. That matters for sandbox proof and special local workflows, but it is not the normal repository posture. PR-bound profiles must keep commit and push acceptance enforcement disabled because hook-time checks cannot safely infer PR-bound review freshness from arbitrary local push context.

The public stance is therefore consistent: flow may block local tracked implementation when the task has not been planned, because that protects the implementation loop. It should almost never block local iteration merely because acceptance has not been finalized. Acceptance becomes mandatory at closeout and remote delivery coordination points.

Current Confidence

The focused evidence supports the policy direction. The observed contracts and targeted tests show that disabled commit and push gates skip without initializing or mutating acceptance state, an explicitly enabled local commit gate can pass with fresh review without requiring closeout validation evidence, memory wake-up and lifecycle diary capture work, inspect issue renders a stable aggregate view, and PR status explains missing acceptance state instead of silently treating PR lifecycle state as acceptance truth.

Those checks support the status summary, but they are not a release-grade claim. The current source worktree has uncommitted flow changes, so this memo should be read as a policy and interface status assessment, not as a final release readiness statement. A release-grade conclusion still requires the broader validation path after the worktree settles: cargo check --manifest-path flow/Cargo.toml -p wap-flow, the relevant focused and broader test suites for touched surfaces, and a final doctor --strict or release-check path appropriate to the change.

Bottom Line

flow is on the right path. The strongest current design choice is the separation between local implementation discipline and delivery governance. Plan-before-implementation keeps LLM work anchored. Inspection, memory, status, and PR summaries keep humans aware. Acceptance closeout and remote-review freshness gates protect delivery. That division is professional, operator-readable, and compatible with agent autonomy because it governs the handoff surface rather than trying to micromanage every local step.