Beagle SCM

DIS-049 MED: be get file:<repo>?/<project> clones the whole repo, not just the project

The ?/<project> selector should clone ONLY that project shard, but be get clones the ENTIRE multi-project repo (all top-level files + every submodule), and the named project arrives at the parent's stale gitlink pin instead of its own tip. Found creating worktrees for the DIS fix-and-land loop. Method: Issues.

Input

Context

• Repro: be get file:/home/gritzko/beagle-journal?/beagle into an empty dir

  produced the WHOLE journal — CNAME wiki/ html/ blog/ todo/ meta/ assets/ + beagle/ (the codebase as a SUBMODULE) + beagle/abc — not just the beagle project. (new wiki/Worktree.mkd, get html?0f72708f, get beagle?5b11dad9, get beagle/abc?….)

• Worse, the beagle subtree came in at the journal's GITLINK PIN 5b11dad9

  (an old JS-024 commit), NOT the beagle project's own trunk tip 125d5c8f — so you get stale code wrapped in the whole journal, no single-project worktree.

• Intended: ?/<project> selects ONE shard; the clone is that project at its

  own tip, rooted at the worktree (no journal wrapper, no submodule indirection).

• ALSO broken — cloning straight from the codebase worktree path:

  be get file:/home/gritzko/beagle-journal/beagle → sniff: get: cannot restore /home/gritzko/beagle-journal/beagle — no baseline in '.be/wtlog' / SNIFFFAIL / BEDOGEXIT. This MUST work (clone the beagle project to a worktree at its tip). Same no-baseline family as GET-029 (the source wtlog tail is a bare post); fixing baseline resolution likely fixes both.

Goals

• be get file:<repo>?/<project> (and the be:///ssh: forms) clones ONLY the

  named project shard, at that project's own tip, as the worktree root.

Constraints

• Fix the ?/<project> project-selector resolution in the get/clone path

  (keeper/sniff be get, the URI ?/proj handling). Don't regress the no-selector whole-repo clone or submodule recursion when actually wanted.

WIP

Design decisions

• (open) selector semantics: ?/proj = pick that shard as the clone root +

  resolve to the project's tip, vs the current "clone the repo + recurse subs".

TODOs

• Repro-first: be get file:<multiproj-repo>?/<proj> yields ONLY <proj> at

  its own tip (no journal files, no submodule wrapper). Red→green.

• Fix the selector; re-run the get/clone + submodule suites.

Blockers

• None. Blocks clean single-project worktree creation for the Issues loop

  (the recurring be get worktree-setup friction, with GET-029).

Outcome

• LANDED 9e80e5f0 (2026-06-21): BEGetWorktree (beagle/BE.cli.c) now honors

  the ?/<project> selector (sel_proj, prefer it for the title; cross-project selector resolves the SELECTED shard's own tip) and recognizes a secondary-wt (.be-FILE) source (anchor at the shared store from row-0); sniff/AT.c SNIFFAtTailOf reads the project from the row-0 query. be get file:<repo>?/<proj> now clones ONLY that project at its tip. Repro test/get/54+55. Validated end-to-end (clean single-project clone at 9e80e5f0). *Subsumes GET-029.*