ForgeFlow / Reference

Roadmap

ForgeFlow is a software delivery workshop for Claude Code and Codex. This page records product direction; it does not promise dates or imply that deferred work is implemented.

Available Today

The core delivery phases, specialist agents, local project memory, and evidence-based review are joined by the workshop dashboard and Ember. The dashboard balances reported activity, project readiness, context budget, and recorded review outcomes. Supported workflow entrypoints open it once per eligible desktop session. The visual guide and Quick Start cover first use.

Current Priorities

1. Keep install, repair, and release paths trustworthy.
2. Keep review, audit, and context-prep surfaces evidence-backed.
3. Reduce onboarding friction for Claude Code and Codex without broadening automation risk.
4. Keep public docs and runtime behavior aligned.

Active Work Themes

Install And Runtime Confidence

• Keep /update-forgeflow, /forgeflow-version, /forgeflow-health, /forgeflow-update-verify, and runtime-drift checks aligned.
• Preserve explicit manual boundaries for host settings and rollback.
• Verify shared helper behavior in both runtimes while documenting host-specific commands, configuration, and model availability.

Review And Context Quality

• Keep review routing explainable and deterministic.
• Improve context-pack quality, budget guidance, and review-wave follow-through.
• Use Verifier verification and release-readiness warnings to keep high-risk claims grounded.

Onboarding And Adoption Evidence

• Keep first-run, pilot, and support surfaces compact enough for real users to follow without internal maintainer context.
• Prefer public-safe summaries and aggregate evidence over raw local state.
• Fix repeated friction before adding new workflow surface area.

Release And Documentation Discipline

• Keep README, wiki, hosted docs, changelog pointers, and release metadata in sync.
• Avoid count-based or host-specific claims that drift easily.
• Prefer current user paths over internal phase history.

Queued: Review And Execution Evolution

Status: queued behind current work; no implementation has started under this plan and no delivery dates are assigned. The portable roadmap tracks this work as E1–E5; F6.1 remains the current next action. Existing priorities retain precedence.

The phased review and execution plan draws on Jive's execution and decision design. It builds on ForgeFlow's existing PR experience, specialist reviews, routing, context packets, and source-bound task evidence.

1. Define the pilot and evidence contract. Select representative historical review cases, record the current baseline, and specify consequential claims, assumptions, missing evidence, and adoption criteria.
2. Preserve exact evidence across handoffs. Give review inputs and results immutable run identities, bounded previews, full retrieval paths, and explicit freshness and coverage.
3. Focus specialist work and challenge assumptions. Assign concrete review questions, support bounded requests for missing evidence, and independently challenge important approval premises when risk warrants it.
4. Execute deterministic review preparation. Connect existing scope, packet, budget, and wave helpers through the ordinary review entrypoint. Keep judgment with specialists and preserve native authorization and interruption handling.
5. Compare outcomes and adopt selectively. Replay the historical cases with frozen inputs, measure correctness and coordination cost, and retain only improvements supported by the results. Consider bounded model decisions only if a measured workload justifies them.

Each phase has deliverables, dependencies, and exit criteria in the plan. A general graph runtime, replacement agent architecture, eager execution of streamed plans, and a new model-provider dependency remain deferred. Historical cases and measured run evidence stay local; public summaries omit private project details.

Deferred By Default

The following stay out of scope unless new evidence justifies them:

• hosted telemetry or remote analytics
• automatic GitHub or PR mutation
• CI auto-push or auto-merge behavior
• broad LLM-generated patching
• multi-fix autobatching across unrelated findings
• full runtime call-graph claims

How To Prioritize New Work

• Prefer fixes backed by smoke failures, release-readiness failures, pilot evidence, or repeated user confusion.
• Prefer smaller changes that improve install confidence, review correctness, or docs accuracy.
• Defer speculative helpers when an existing command or document already covers the need.