standards/ROADMAP.md

# ROADMAP — Standards

Longer-term backlog for the standards repo: future agents, commands, and cross-repo
standards to hash out and build later. Near-term status lives in `AGENTS.md` →
`## Current state`. Items here are parked, not committed — we iterate on them when we pick
one up. Newly captured cross-repo ideas land in `INBOX.md` first and graduate here on
triage.

---

## 1. Cross-repo quality-gate standard (linters / pre-commit hooks / CI)

**Why:** with agents writing the code, these stop being developer conveniences and become
the falsifiable rails that let an agent check its own work — write, get told exactly what's
wrong, iterate, verify. The *standard* is authored here; *application* is per-repo (in each
repo's AGENTS.md), because what's best-in-class differs by language/stack.

**The principle to encode:** every code repo should give its agent a fast, deterministic,
agent-runnable feedback loop — the subset of checks that run without a human and can't be
skipped. Tier it:

- **Linter/formatter** — per-stack (e.g. ruff/black, eslint/prettier, gofmt). Fast, runs on
  every change; the agent fixes before moving on.
- **Pre-commit hook** — the unskippable gate: runs the linter + quick tests and blocks the
  commit if they fail. This is the highest-ROI piece and the first to add.
- **CI on push** — the heavier rebuild + full test suite. Lower priority for solo repos on
  Gitea (Gitea Actions exists); add when a repo has real collaborators or releases.

**This repo's own first instance:** it's Markdown + symlinks, so its quality gate isn't a
code linter — it's a pre-commit hook that runs the **structural checks** this repo already
has an agent for: relative-symlink integrity (`AGENTS.md ← CLAUDE.md`,
`docs/guides/* ← .claude/rules/*`, the `adapters/` directory symlinks) and internal-link
validity. The `portability-checker` agent encodes the invariants; the hook makes the
deterministic subset unskippable. Build this as the worked example of the standard. Concrete
checks to start with: (a) the `type` enum is identical across `guides/capture.md`,
`INBOX.md`, and `AGENTS.md`; (b) `CLAUDE.md` is a relative symlink resolving to `AGENTS.md`;
(c) every `adapters/claude/{commands,agents}/*.md` wrapper has a matching `guides/<name>.md`
substance file (no wrapper-without-guide drift).

**Open questions:** one shared hook framework (pre-commit.com) vs. hand-rolled per repo;
how the standard gets *adopted* into a repo (a `/harden` command that installs the right
linter+hook for the detected stack?); whether to define a minimal "agentic-ops baseline"
checklist doc alongside the other four standards docs.

## 2. `roundup` — cross-project status agent (the inverse of capture/triage)

**Why:** a global "what should I do next / which project to focus on" view. Capture/triage
push items *down* into project repos; roundup reads back *up* across all of them.

**Shape:** a command (`/roundup`, run from `~/Projects`) that fans out one read-only
subagent per repo to read that repo's `AGENTS.md` (`## Current state`) and `ROADMAP.md`,
plus reads the standards `INBOX.md` for not-yet-triaged items. It synthesizes **one
aggregated to-do list across all projects, grouped by priority**, including items that
haven't been pushed down to a repo yet. Mirror `full-eval`'s orchestrator pattern: fan out,
then synthesize into one report; the per-repo readers can be the generic `Explore` agent or
a small dedicated reader.

**Division of labor (the user's explicit call):** the agent *reads and reports* — it
gathers and presents findings grouped by priority; it does **not** decide the best use of
time. Prioritizing across projects is a back-and-forth the user does on top of the report.
So the output is a clean, evidence-backed inventory, and the "what's actually worth doing
now" conversation happens after, in the main thread.

**Open questions:** which folders count as "my projects" (scan `~/Projects`, skip non-repos
and the standards repo itself?); how to keep it cheap (cap readers, summarize hard); whether
roundup output is ephemeral or written to a `STATUS.md` in the standards repo for diffing
over time like `EVALUATION.md`.

## 3. Deterministic inbox surfacing — SessionStart hook (optional upgrade over the portable line)

**Why:** the portable mechanism (the inbox-check line in every repo's AGENTS.md) is
model-interpreted and therefore skippable. A Claude `SessionStart` hook that greps
`INBOX.md` for the current repo's tag and prints matching items is deterministic and
unskippable — the same quality-gate logic as item 1, applied to capture.

**Tradeoff:** hooks are Claude-specific and per-repo, so they don't travel to other vendors.
Decision already made: keep the AGENTS.md line as the **belt-and-suspenders portable
default**, and offer the hook as an opt-in upgrade for repos where you want the guarantee.
Possible form: a snippet the quality-gate `/harden` flow (item 1) installs alongside the
linter hook.

## 4. Thread the inbox-check line into bootstrapping

**Why:** right now adding the portable inbox-check line to a repo is manual. It should be
automatic so every repo inherits it.

- Add the line to the AGENTS.md template in `retrofit-playbook.md` (Step 1, prompt A) and
  to the `/retrofit` guide's Phase 4.
- Thread the canonical `.gitignore` block (now in `portability.md` → "What git tracks")
  into `retrofit-playbook.md` Step 0 and the new-repo bootstrap, so every repo's committed
  `.gitignore` carries it rather than relying on a global excludesfile.
- Consider a one-time sweep command that adds it to every existing repo's AGENTS.md.
- Decide whether the canonical wording lives in `how-i-work.md` (so it's truly universal)
  or stays a per-repo line.

## 5. `new-project` — idea → scoped → scaffolded → Gitea repo

**Why:** the inverse of `/retrofit`. Retrofit moves an *existing* project onto disk; this
takes a captured `(new)` inbox idea and turns it into a real, standards-compliant repo. It
closes the capture loop: `/capture (new) …` → bootstrap → a repo that already has AGENTS.md,
the CLAUDE.md symlink, ROADMAP.md, the canonical `.gitignore`, and the inbox-check line.

**Shape:** a command (`/new-project`, run from `~/Projects`), main-thread and collaborative
— scoping is a conversation, not a delegated job. Phases:

1. **Workshop the scope** — back-and-forth to sharpen objectives, non-goals, stack, and the
   key early decisions. Pull the seed from the `(new)` inbox item if one exists. This is the
   high-value step and stays interactive (like roundup, the reasoning is the user's).
2. **Seed prompt** — synthesize the workshop into a concrete project brief / initial build
   prompt plus a scaffolding plan; get the user's sign-off.
3. **Scaffold** — create the new folder under `~/Projects`, write the initial AGENTS.md
   (from the brief) + CLAUDE.md symlink, ROADMAP.md, README, the canonical `.gitignore`,
   `.claude/` wiring, and the starting directory structure. Compliant from line one.
4. **Publish** — `git init` + initial commit, create the Gitea repo, add the remote, push
   (reuse retrofit-playbook Part 4; if no Gitea API token is available, hand back the manual
   "create empty repo, copy URL" step). Then remove the `(new)` item from the inbox.

**Open questions:** Gitea repo creation — API token vs. manual UI step; how much scaffolding
is generic vs. stack-specific (does it call a `/harden` step from item 1 to install the
stack's linter+hook?); whether the workshop output also seeds the first `## Current state`.