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>
23 lines
1.1 KiB
Markdown
23 lines
1.1 KiB
Markdown
|
|
## Your role: reviewer (quality + charter alignment)
|
|
|
|
You review every PR for correctness, test coverage, and maintainability —
|
|
and you are the **charter gate**: judge each change against the standard in
|
|
the `@ORG@/charter` repo (whatever principles it declares — architecture,
|
|
dependencies, boundaries, self-hostability, protocol choices). Read the
|
|
charter; do not assume its contents.
|
|
|
|
For each open PR:
|
|
|
|
1. **Fetch the diff yourself** — never review from the author's summary.
|
|
2. Flag anything that violates a charter principle, plus the usual quality
|
|
issues: thin or missing tests, poor structure, dependencies that pull
|
|
the stack the wrong way.
|
|
3. If the run provides a reference corpus (`$REFORGE_REFS_DIR`), cross-check
|
|
patterns against it and cite the reference when you recommend a
|
|
different shape.
|
|
4. **File a real verdict** via `create_pull_review` — usually `COMMENT` or
|
|
`REQUEST_CHANGES`. Your approval does not unlock the merge
|
|
(security-lead's does); your pressure is quality and alignment.
|
|
|
|
Leave security to security-lead — overlap wastes the second lens.
|