Skip to content
Documentation
Status

Status

FORGE is an internal tool first. It sits behind CORE’s sign-in and can be narrowed further with an optional allowlist. It has never been deployed. This page states each part’s status as the source and its own CLAUDE.md record it. Anything not listed here should be treated as not existing.

Built and tested

  • The backend (grpc/): the Identity, Forge and Project services, the shared chat service, and the deprecated forge.v1.ChatService alias. See the API reference.
  • The studio (flutter/): the lanes canvas, the project’s chat console, the component palette, the inspector, and the proposed-steps list.
  • Projects and lanes: forge.yaml v1, one repo per project, lane work orders labelled lane:<id>.
  • The planner: the sovereign in-cluster model proposes steps, a shared judging gate checks each step, and the owner approves.
  • The embedded skeletons for the two kinds, web and pipeline. See App kinds.
  • The actor audit and the per-person chat store in FORGE’s encrypted appfs root.
  • CORE’s side, merged in core: the /forge/ proxy under CORE’s sign-in, the FORGE rail category (the chat history), the forge-backend image recipe, and the on-host manifest (namespace forge-system, network policies that admit only CORE’s console). Merged is not the same as applied. Whether any of this runs on a box has not been verified.

Armed, nothing landed

  • The coding agent. CORE’s core-forge-run.yml runs every six hours. It picks an open forge issue, runs a coding session, pushes commits and opens a draft PR in that repo. It never merges. No forged PR has landed yet.
  • Central verification. CORE’s verify sweep posts core/ci on FORGE’s repo and on every forged repo. FORGE’s own documentation says that whether CORE posts it today is not verified from FORGE. Until it does, a Verification stage reads “No verification yet”.

Not built

  • Deploying the apps FORGE ships. There is no per-app namespace, route or DNS. The lane’s last stage reads Go online · LATER for a web lane and Run on RIVER · LATER for a pipeline lane. When the studio says “live”, it means the last verification was green. It does not mean the app is serving. App.app_url stays empty.
  • The RIVER runtime. Pipelines are authored in the Runink integrator formats only. The pipeline skeleton seeds just an AGENTS.md stack contract, and nothing runs a pipeline.
  • Connectors in forged apps. Connectors execute only inside FACE. In FORGE a connector can only be declared on a lane, as a CORE connection picked by name.

Things FORGE deliberately does not have

  • No domain, DNS record, OAuth client, login screen, session store or sign-out. CORE owns access. See Inside CORE.
  • No per-repo CI and no per-repo credentials in any forged repo. CORE verifies centrally.
  • No REST API. The wire is gRPC and gRPC-web only.
  • No workflow engine. The palette’s “Use as brief” compiles text that you edit and send.
  • No external AI SDK or endpoint. The planner calls the platform’s own OpenAI-compatible plane over plain net/http.

Sources

CLAUDE.md (“Phases — honest status”, “Verification — CORE, centrally”); core’s CLAUDE.md (“Central verification (core/ci)”); flutter/lib/features/forge/palette/catalog.dart (the notAvailable lines).

Troubleshooting