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>
45 lines
1.8 KiB
Markdown
45 lines
1.8 KiB
Markdown
# Charter — <your project>
|
|
|
|
This is the standard every change in the run is judged against. It is seeded
|
|
into the forge as `@ORG@/charter` (README.md) and every review should cite
|
|
it. Fill in the sections below; delete the guidance italics.
|
|
|
|
## Mission
|
|
|
|
*What is this stack, and what is the run trying to achieve? One paragraph.*
|
|
|
|
## Principles (what "aligned" means)
|
|
|
|
*The rules a change must respect — architecture, dependencies, boundaries,
|
|
security posture, self-hostability, protocol choices, licensing. The
|
|
`reviewer` role enforces these as the "charter gate", so be concrete: a
|
|
principle a reviewer can't check is decoration.*
|
|
|
|
- *e.g. No closed/hosted control-plane dependencies — everything must be
|
|
self-hostable.*
|
|
- *e.g. Prefer a standard wire protocol over private in-process coupling
|
|
between components that might not always be colocated.*
|
|
- *e.g. Secrets never land in code or config; demo/test gates must never be
|
|
reachable in a production posture.*
|
|
|
|
## Intent docs (Phase A sources)
|
|
|
|
*In Phase A the target repos are off-limits — roles work from recorded
|
|
intent. List the docs that intent lives in (roadmaps, ADRs, vision notes)
|
|
and where to find them. If a reference corpus is available, say so and note
|
|
that its path is in `$REFORGE_REFS_DIR`.*
|
|
|
|
## Test harness
|
|
|
|
*How does a role run tests inside the sandbox? Name the commands, any local
|
|
services, and what needs the human to arrange (real infra a role can't
|
|
reach).*
|
|
|
|
## Review lenses
|
|
|
|
- **security-lead** — the merge gate. *List the stack-specific hotspots to
|
|
threat-model and the demo/env gates that must never reach production.*
|
|
- **reviewer** — quality + charter alignment (this document).
|
|
- *Add project-specific reviewer roles here (e.g. a protocol-conformance
|
|
lens). For each: add its brief as `<role>.md` in your agents dir, add its
|
|
username to `reforge.roles`, and describe its lens here.*
|