claude-forgejo-sandbox/templates/reforge/agenda.md
Padreug df0fd9a9ba 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>
2026-07-18 22:51:47 +02:00

1.3 KiB

Run agenda —

Everything this particular run must address. Group items and give each a short id (A1, B2, …) so issues and reviews can trace back to it. The machine-readable twin of this file is issues.tsv (what reforge-kickoff files as issues) — keep the two in sync.

A. Production-readiness

  • A1 — Security audit per repo (auth, key custody, secrets, injection).
  • A2 — Bug hunt on the critical paths.
  • A3 — Refactor opportunities that are cheap now, expensive after release (strict-from-the-start — no compatibility shims pre-launch).
  • A4 — Test-coverage review against the charter's test harness.
  • A5 — Synthesize GAMEPLAN.md: what stands between this stack and production-ready, ordered, with owners. (PR into the charter repo.)

B.

  • e.g. an architectural evolution the run should evaluate and stage as tracked divergences in Phase B.

C. Coherence

  • C1 — Map every inter-component contract (who calls whom, over what).
  • C2 — Check each contract against the charter's boundary principles.

Outputs (deliverables of the run)

  • Issues traceable to these agenda items.
  • Reviews on every PR (security + charter, plus any project lens).
  • GAMEPLAN.md PR'd into the charter repo.