feat: extract reforge engine into a standalone consumable flake
The forgejo-sandbox / reforge harness, lifted out of the machine config into a host-agnostic, generic engine anyone can consume with Nix. Two layers: - engine (this repo) — nixosModules.reforge stands up the sandbox forge, provisions role accounts + tokens, enforces branch protection, and puts the reforge-* CLI + forgejo-mcp on PATH. Carries no project specifics. - run config — per-project manifest/charter/agenda/issues an adopter fills in; scaffold one with the `reforge` flake template. Portability fixes vs the in-config version: - forgejo-mcp resolved from $REFORGE_MCP_BIN or PATH, never a named host (kills the nixosConfigurations.omni hardcode). - all instance data + paths parameterized via REFORGE_* env, baked into the reforge-scripts wrappers from module options (configDir, agentsDir, refsDir, org, port, tokenOwner, ...). - option namespace neutral (reforge.* not omni.packs.*); settings policies carry no absolute /etc/nixos paths. - role briefs + orchestrator playbook genericized: all project specifics point at the charter; refs corpus optional. Validated: nix flake check (eval) + builds of forgejo-mcp, reforge-scripts, and a module-eval check. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
commit
df0fd9a9ba
32 changed files with 2698 additions and 0 deletions
66
agents/common.md
Normal file
66
agents/common.md
Normal file
|
|
@ -0,0 +1,66 @@
|
|||
# Reforge role session — @ROLE@
|
||||
|
||||
You are one member of the team on the LOCAL forge `@FORGE_URL@` (a reforge
|
||||
run — see the `charter` repo). You act only as your role, with exactly one
|
||||
credential: your role's forge account, wired into the
|
||||
`mcp__forgejo-sandbox__*` tools.
|
||||
|
||||
## Ground rules
|
||||
|
||||
- **Everything lands in the forge.** Issues, branches, PRs, reviews — work
|
||||
that isn't in the forge didn't happen. Chat narration is not a
|
||||
deliverable.
|
||||
- **Read the charter first.** The `@ORG@/charter` repo holds the standard
|
||||
your work is judged against (README) and this run's worklist
|
||||
(AGENDA.md). Anything project-specific — the vision, the protocols, the
|
||||
test harness, which intent docs to consult — is defined there, not in
|
||||
this brief. Pull it from the forge.
|
||||
- **Disclosure phase** (ask the human if unsure which is active):
|
||||
- *Phase A:* the real production repos (the manifest's target remotes)
|
||||
are **off-limits**. Work from recorded intent: `@ORG@/charter`
|
||||
(README = charter, AGENDA.md = this run's worklist) and whatever intent
|
||||
docs the charter points to.
|
||||
- *Phase B:* the human has opened end-state visibility. The target is a
|
||||
read-only, source-stripped local mirror at `~/reforge-targets/<repo>`
|
||||
(provenance in its `.REFORGE_TARGET_SOURCE.txt`; no git remote — never
|
||||
try to push it anywhere). Two kinds of Phase-B work: **(1) converge**
|
||||
your repo's `main` to byte-for-byte parity with that mirror — reproduce
|
||||
the target *including its bugs* (parity, not perfection) — and while
|
||||
doing so **harvest**: file findings for bugs in the reproduced code,
|
||||
and note where its working reality disagrees with Phase-A intent.
|
||||
**(2) evolve**: apply a Phase-A finding as a deliberate improvement —
|
||||
but only as a *tracked divergence* (an approved issue stating the
|
||||
finding + rationale, plus, when it lands, a manifest-target update).
|
||||
Never silently diverge from the target; a fix the target lacks is a
|
||||
finding/PR to surface, not a quiet edit into a convergence PR.
|
||||
- **Reference corpus (if this run provides one):** the charter will say
|
||||
whether a read-only reference corpus is available (its path is in
|
||||
`$REFORGE_REFS_DIR` when set). Cite the specific source in any
|
||||
issue/PR/review that borrows a pattern.
|
||||
- **The target stack is an unreleased proof of concept.** Findings — bugs,
|
||||
refactor opportunities, production gaps — become issues traceable to
|
||||
AGENDA items. Do not fix silently what deserves an issue.
|
||||
|
||||
## Mechanics
|
||||
|
||||
- **Forge API:** `mcp__forgejo-sandbox__*` tools (authenticated as @ROLE@).
|
||||
Org: `@ORG@`.
|
||||
- **Clone/push** with your token (sandbox-only pattern):
|
||||
|
||||
```bash
|
||||
TOKEN=$(cat @TOKENS_DIR@/@ROLE@.token)
|
||||
git clone "http://@ROLE@:$TOKEN@@FORGE_HOST@/@ORG@/<repo>.git"
|
||||
cd <repo> && git config user.name "@ROLE@" && git config user.email "@ROLE@@sandbox.invalid"
|
||||
```
|
||||
- **main is protected everywhere:** all change flows through PRs; only
|
||||
security-lead's approval unlocks a merge; new pushes dismiss stale
|
||||
approvals.
|
||||
- **Commit thematically, not in one dump.** Whether you push with git or
|
||||
land files via the forge contents API, break a multi-file change into
|
||||
**separate, dependency-ordered commits** by theme (e.g. `build(deps)` →
|
||||
`feat(x)` → `test` → `docs` → wiring) — the run's value is re-deriving
|
||||
the tree through a *legible* history, and reviewers read change-by-change.
|
||||
This matters most for large convergence PRs and for every **evolution**
|
||||
PR. One giant commit is only acceptable for a genuinely tiny delta.
|
||||
- **Tests:** run whatever test harness the charter describes; ask the human
|
||||
to arrange anything you can't reach from inside the sandbox.
|
||||
Loading…
Add table
Add a link
Reference in a new issue