#46 f0rge repo list: discover f0rge repos on the box (DEFERRED — owner deciding scan vs remember)

opendeferredopened
details
updated
id
df02571d-47b7-4dab-9077-73ecb58da12e

id: df02571d-47b7-4dab-9077-73ecb58da12e title: 'f0rge repo list: discover f0rge repos on the box (DEFERRED — owner deciding scan vs remember)' state: open labels:

id: df02571d-47b7-4dab-9077-73ecb58da12e title: 'f0rge repo list: discover f0rge repos on the box (DEFERRED — owner deciding scan vs remember)' state: open labels:

STATUS: DEFERRED by owner 2026-09-08 — do NOT work until the owner says go. Filed because the cost of forgetting exceeds the cost of filing. Label: deferred.

TRIGGER: the fix-issue-record agent spontaneously tried f0rge repo list mid-mission while looking for other f0rge repos to poke. The gh-literal shape pattern-matches (gh repo list is a first-class gh command), and the fleet value is real: an agent in repo A should be able to discover the other f0rge repos on the box.

DESIGN FORK to think through (owner): (a) SCAN — f0rge repo list scans a configured root (~/src or ~/.config/f0rge/root) for dirs containing .forge/, prints path + remote + open-issue count (derived at print time). Zero stored state, always current, bitter-lesson-clean. (b) REMEMBER — a touch-log: the CLI appends to ~/.config/f0rge/repos.yml on init/clone/pr-merge; list prints it. Convenience state only, NEVER authoritative (repos born outside the log must still be discoverable via scan).

Open questions for the owner: include non-.forge clones or filter to .git+.forge? does the folder-mirror invariant apply (a repo verb has no .forge/repos/ folder — it is a user-level verb like spec, arguably outside the in-repo entity invariant)? multi-owner sharing? shell-history-style pruning?

CONSTRAINT (bitter lesson): never store derived state as truth; if we "remember", it is a cache — scan is the source of truth.

FIX LATER, only after the owner picks a fork.

REFINEMENT after the triggering incident was dissected with the owner (2026-09-08): The agent reached for repo list with CROSS-REPO INTENT, not discovery-for-its-own-sake: it found a bug while working in wr1te and wanted to FILE IT ON THE F0RGE TRACKER using f0rge itself — issue create against another project's .forge. It gave up on the failed verb with no fallback (no whole-computer search), so the finding went to chat instead of the ledger. The loop that makes this valuable: bug found in project A that belongs to project B gets ROUTED into B's tracker the same session, by the agent that found it. Today the router is the owner; the forge could be.

gh-literal precedent hardens the shape: gh repo list + gh issue create -R <owner/repo> are a PAIR — discovery feeding targeting. Our local version: f0rge repo list (scan paths) + --repo <path> on issue/pr verbs (target another repo's .forge). Same-owner multi-repo is simpler than federation: no trust layer, just discovery + targeting + write discipline (file + commit into the target repo's tree). Also: when the target is not found, the scan must say WHERE it looked (the give-up was a silent dead end — the same class as #37 parse hints).

STILL DEFERRED. Owner deciding: scan vs remember; how --repo validates target state (uncommitted .forge? concurrent agents? — likely just document + refuse on dirty .forge).

PROVENANCE THREAD (owner Q 2026-09-08, appended): can f0rge tell local vs -R external filing? Only at create-time — the resulting file is identical either way; a "via -R" marker is a STAMP, not a distinction. Judgement: dont stamp the entity (derived state; gh doesnt; and provenance must never become policy/trust tiers). Two clean audit homes: (a) commit-level — external filing commits a distinct message ("issue from <repo>: #N") so provenance is a git-log query, zero schema; (b) optional author field (spec already has Optional author on comments; gh shows issue author) auto-stamped from git config or the -R remote — the upgrade path if visible provenance is ever wanted. Lean (a); never policy on provenance.

ALT PLAN — operator guidance note (owner 2026-09-08, STILL DEFERRED; the note is recorded as an option, not built): if an agent runs f0rge repo list, it returns a brief note: "f0rge is a local forge; follow project or operator instructions to find other projects" and exits 0. Purpose: eliminate the observed SILENT DEAD END (the triggering agent gave up when the verb failed and never searched). A placeholder that answers beats a missing command that stalls. Zero machinery: no scan, no registry, no provenance. The full design fork (scan vs remember) and the provenance thread (optional author, auto-stamped from -R) stay deferred with this issue — the note is the cheapest thing that passes, and if it proves insufficient the fork is still there. Owner: still thinking; there are unresolved issues with the fuller design.

Comments (0)

No comments yet.

all issues