OpenFang’s roadmap silence now sits beside two bounded runtime repairs

RightNow-AI/openfang issue #1275 is the inspected primary source: “Project status / roadmap after v0.6.9.” The related records below were inspected as supporting context rather than independent confirmation.

The facts

- RightNow-AI/openfang issue #1275 was created 2026-07-31T08:28:30Z and was open at inspection; its title is “Project status / roadmap after v0.6.9.” - RightNow-AI/openfang PR #1278 was created 2026-08-04T18:44:07Z and was open at inspection; its title is “fix(runtime): cancel WASM watchdog on early exit.” - RightNow-AI/openfang PR #1277 was created 2026-08-04T18:31:52Z and was open at inspection; its title is “fix(kernel): scope collect step to preceding fan-out outputs.” - The repository reported 18076 stars, 118 open issues, default branch main, and last push 2026-07-02T08:13:12Z. - The latest tagged-release baseline checked was v0.6.9 published 2026-05-12T18:42:42Z.

What changed

RightNow-AI/openfang issue #1275 reports: Hi Jaber, I’m evaluating OpenFang for a longer-term self-hosted deployment. The last release and commit appear to be v0.6.9 from May 12. Could you share whether active development is expected to continue, and whether there is an updated roadmap or approximate outlook for v1.0? I understand that open-source work may pause or priorities may change. A short status update would help users assess whether OpenFang remains a suitable choice for new deployments. Thanks you! Jochen

RightNow-AI/openfang PR #1278 reports: Fixes #1241 Summary sandbox.rs spawns a detached OS thread per WASM execution as an epoch watchdog: it sleeps the full timeout_secs and then bumps the **shared** engine epoch. When execution finishes early (success, fuel exhaustion, or error), the thread keeps sleeping and eventually calls increment_epoch() on the shared engine — which can interrupt a *different* execution still running on the same engine. Beyond the reported thread accumulation under load, this is a cross-execution correctness bug: a stale watchdog can cut a concurrent execution short with a false "timed out" error. Changes The watchdog thread now polls a cancellation flag while sleeping (50ms steps) and exits immediately when execution has finished. A small RAII guard (WatchdogCancel) sets the flag on drop, so cancellation is guaranteed on every exit path of execute_sync — success, fuel exhaustion, epoch interrupt, or any error. Added a regression test that runs a long loop and a

RightNow-AI/openfang PR #1277 reports: Fixes #1253 Summary The collect step joins the whole run-wide all_outputs buffer instead of only the outputs of the immediately preceding fan-out group. A workflow shaped sequential → fan_out → fan_out → collect therefore feeds the earlier sequential step's output into the collected payload, and multi-phase workflows keep carrying stale pre-fan-out context across later collect steps. docs/workflows.md specifies: *"The collect step gathers all outputs from the preceding fan-out group"* — the implementation did not match that contract. Changes execute_run now keeps a fan_out_start marker, reset to all_outputs.len() at the beginning of each fan-out group. The collect step joins all_outputs[fan_out_start..] instead of the full buffer, so it merges only the outputs produced by the immediately preceding fan-out group. Added a regression test covering sequential → fan_out → fan_out → collect, asserting the collected payload contains both branch outputs and not the earlier sequential output. Behavior for workflows without a preceding fan-out

Why it matters

The patches are useful, but they do not answer the roadmap question. Operators need to distinguish isolated maintenance from a maintained release line before treating activity as recovery. The operator test is whether persisted state, execution authority and the visible outcome describe the same event after retries, restarts or delegation.

Current

The primary record was open when captured on 2026-08-05. The release baseline was v0.6.9 published 2026-05-12T18:42:42Z. Repository metadata, pull requests, issues, release records, Google News discovery, Hacker News discovery, Lobsters, Metamesh and the rendered ClawCharts row were checked. ClawCharts selected the subject; it did not prove the claim.

Evidence

The primary URL is https://github.com/RightNow-AI/openfang/issues/1275. Supporting records are https://github.com/RightNow-AI/openfang/pull/1278 and https://github.com/RightNow-AI/openfang/pull/1277. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts, reproductions and deployment observations remain attributed to their authors unless explicitly identified as independently rerun.

Source boundary

Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.

Operator take

Watch for maintainer response and a release plan; test watchdog cleanup and fan-out scoping independently, and do not infer project revival from two open patches. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently after intervention.

Caveat

Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.

Source inspected; source state, environment and release boundary remain explicit.