PATCH: absorb another branch's work into the worktree

PATCH absorbs commits from another branch into cur's worktree and records the absorbed sha(s) in .be/wtlog for the next POST to consume; it never commits on its own. The cycle is patch → test → post — run once per merge, cherry-pick, or squash, or looped per commit for rebase — so every commit that lands is a tested commit, never a chain of unverified work. PATCH is one verb in the Beagle Verbs vocabulary, and unlike GET it weave-merges theirs rather than overwriting the worktree.

Does not commit: the absorbed sha(s) are staged in .be/wtlog, and the next POST turns them into a commit with a header.
PATCH selects scope only: the trailing ! picks one commit vs the whole branch; provenance is decided later, at POST.
A dirty wt is fine: a 3-way WEAVE merges theirs against the wt's current bytes, so dirty files never cause a refusal.
Conflicts are loud: a conflict hits stderr and exits non-zero, stopping an unattended patch && post before a bad commit.

Three shapes

The PATCH URI form selects scope only — the bang ! on ?br is the whole-branch toggle — and every shape takes the usual extras (//host to fetch first, ./path to scope). The operation (merge/rebase/squash/cherry) is scope-at-patch plus provenance-at-POST per the dirty-words post; PATCH never carries a #message.

?<br> one commit: absorb the next not-yet-replayed commit on ?br (bare branch = one — a flip from the old squash).
?<br>! whole branch: replay fork..br.tip in one wt-merge — the bang means "the entire branch", not "one".
#<hash> named commit: absorb the one named commit, after which POST records a picked header (next to foster).

CLI use

PATCH chooses scope; the named op is PATCH-scope plus POST-provenance — rebase-one = ?br + post #!, merge = ?br! + post '#msg', squash = ?br! + post '#msg!', cherry = #sha + post #!.

be patch ?feat absorbs the next commit of feat; pair with be post #! for a rebase-step, loop it for a full rebase.
be patch ?feat! absorbs the whole branch; be post '#msg' then merges (refer), be post '#msg!' squashes (forget).
be patch ?..! replays the parent's whole stack into the wt, while be patch ?./fix absorbs one commit of a child branch.
be patch '#abc1234' absorbs one named commit (cherry-pick with be post #!); be patch ssh://origin?main! fetches then absorbs the whole branch.
be patch file.c?feat applies one file's version from ?feat, recording no foster row.
be patch spot:#'Old'->'New'.c delegates an in-place structural rewrite to spot.
Multiple PATCHes compose: each PATCH appends a patch row the next POST consumes.

Ancestor-skip walk

A whole-branch ?br! replays only the commits cur doesn't already have; a one-commit ?br finds the next un-absorbed commit by walking the source's first-parent chain.

Whole-branch ?br! replays only commits not already reachable from cur via parent ∪ foster.
picked headers are dedup-only and do not participate in reachability.
One-commit ?br walks ?br's first-parent chain and stops at the first sha already reachable from cur.

Merge base: full stack vs single commit

The scope splits by merge base, which lets one verb be git's merge, rebase, and cherry-pick: whole-branch ?br! weaves the full fork..tip stack against auto-LCA(cur, theirs), while a named commit or one-commit ?br weaves one commit against its parent.

Whole-branch ?br! uses auto-LCA(cur, theirs) and replays the full not-yet-reachable stack — git's merge / pull --squash.
A named commit or one-commit ?br uses the base parent(theirs), weaving that one commit's diff — git's cherry-pick/rebase.
All shapes are merge-then-POST; only the base differs at PATCH and the provenance is recorded at POST, so one verb covers four git commands.

Weave merge

PATCH never refuses on dirty files: it runs a 3-way WEAVE with the absorbed commit on the theirs side and the wt's current bytes on the ours side, so PATCH-on-PATCH composes by construction.

The ours side is the wt's current bytes, including user edits and any prior output, so a prior absorption reads as an edit.
Unresolvable conflicts are marked token-level with 4-char delimiters (<<<</>>>>), not git's 7-char line markers.
git mergetool and existing UIs won't recognize the token-level markers — hand-edit, or enumerate via a diff:? view.

Path-scoped PATCH

A non-empty path slot scopes the absorption to those paths, but records no provenance — a partial absorption is not a faithful DAG commit.

Path-scoped be patch file.c?feat lands theirs bytes for those paths only.
A path-scoped row carries the path but no &theirs slot, so POST emits no provenance header and counts zero commits.
Use a full (no-path) PATCH shape if you want POST to record provenance.

Reporting and status

Every PATCH prints a ULOG-style report — one line per applied commit and touched file, <verb> <status> <path-or-uri> — so the patch-test-post loop stays auditable.

applied: the file was clean (baseline or stamped) and overlaid with theirs bytes, no merge needed.
merged: the file had non-baseline bytes and theirs touched it, and WEAVE integrated both sides cleanly.
mod: ours diverged from the merge base but theirs didn't touch this path, so the bytes are kept as-is (fork-relative).
conflict: non-baseline bytes theirs touched but WEAVE couldn't resolve, leaving markers in the file and a non-zero exit.

Open questions

Two PATCH-side formats are still unsettled, both about how downstream tools read PATCH's output.

The token-level 4-char conflict delimiters need a stable wire format for bro, graf-resolve, and a git mergetool adapter.
A "partial picked" header naming <sha>:<path> for path-scoped forensics is a possible future extension.