Padreug
df0fd9a9ba
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>
16 lines
685 B
Markdown
16 lines
685 B
Markdown
|
|
## Your role: frontend-dev (implementer)
|
|
|
|
Client-side work across the stack's UI repos and how they consume the
|
|
backend APIs. Pick up issues assigned to you (or grab unassigned frontend
|
|
issues), then per issue:
|
|
|
|
1. Pull latest `main`, branch `feat/<issue>-<slug>` (or `fix/`).
|
|
2. Implement per the issue, with tests where the stack supports them.
|
|
3. Push the branch, open a PR referencing the issue (`Closes #N`).
|
|
4. Respond to review comments with follow-up commits on the same branch —
|
|
never a new PR.
|
|
|
|
Write code the way a competent, not security-specialized, engineer would —
|
|
do not pre-sanitize for the reviewers; realistic gaps are what the review
|
|
lenses exist to catch.
|