Skip to content

Make forge harness-agnostic: run on Claude Code and Pi/open models #2

Description

@dasirra

Adversarially planned, pending human review. Review each sub-issue and edit as needed before implementing.

Goal

Forge is a three-command idea-to-PR pipeline that runs only on Claude Code today. This epic makes the same three commands also run on the Pi coding agent with open-weight models (GLM-5.2 for every role), without dropping Claude Code support and without forking roughly 800 lines of methodology prose into two drifting copies. One methodology, two harnesses.

Proposed solution

Running forge does not change for the developer: same commands, same order, same interview-plan-build pipeline. Underneath, the command prose stops naming any Claude-specific tool or model and instead uses generic role-and-verb language. Each harness supplies a small binding doc that translates those verbs into its own concrete tools. Both harnesses load the same command files; each reads its own binding. The Claude Code binding reconstructs today's behavior exactly; the Pi binding maps every role to GLM-5.2, worktrees to git, questions to plain chat, review to a spawned reviewer, and the browser to Playwright. Open-model quality risks are settled by one empirical run before any hardening is built.

flowchart TD
    Dev([Developer runs a forge command])
    Cmd[One shared harness-neutral command file]
    Dev --> Cmd
    Cmd --> V{Every verb has a binding entry}
    V -->|No| Defect[STOP unmapped verb is a defect]
    V -->|Yes| Q{Which harness}
    Q -->|Claude Code| CB[Claude Code binding]
    Q -->|Pi open model| PB[Pi binding]
    CB --> Same([Same methodology same pipeline])
    PB --> Same
Loading

Key decisions

Decision Choice Why
Command copies One neutral set, no fork Two copies of active methodology drift
Model names in prose Deleted, not tiered Context separation, not weights, makes an adversary
Harness differences Per-harness binding doc A thin adapter is the smallest change that keeps both working
Native surface on Pi Dropped No open-weight Pi setup has computer use
Pi environment Provisioned as its own issue It is a hard precondition, not an assumption
Compensation depth Gated on one empirical run Invest on evidence, not speculation

Phased delivery (build order)

Phase 1 - Foundation

Phase 2 - Pi environment and binding

Phase 3 - Validation

Phase 4 - Conditional hardening

flowchart LR
    C1[C1 Neutralize and Claude binding]
    C2[C2 Provision Pi harness]
    C3[C3 Pi binding]
    C4[C4 Validation]
    C5[C5 Hardening]
    C1 --> C3
    C2 --> C3
    C3 --> C4
    C4 ==> C5
    C1 --> C5
Loading

Out of scope

  • Rewriting the methodology itself; only its harness-specific surface changes.
  • Restoring the native/computer-use surface on Pi.
  • Building any open-model compensation before the validation report justifies it.

Planning notes

Adversarially reviewed: 1 critique round, 10 findings addressed (2 BLOCKER, 4 MAJOR, 4 MINOR); critic APPROVED the revision.
Contested items pending human arbitration: none.
Technical contracts: negotiated at /forge:building time, per issue.

References

  • PI.md in this repo (port analysis, uncommitted at planning time).
  • Superpowers references/pi-tools.md binding-doc precedent.
  • Planning conversation, 2026-07-10.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestepicTracking issue spanning multiple child issues

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions