A programmer can merge an engine branch while selecting only Source and
Config, without downloading unrelated art. The view controls local files, not
which changes count as integrated. Merge still records complete branch ancestry;
cherry-pick still records the selected ordinary change's provenance.
scribe workspace view set --view Source --view Config
scribe merge development --revision 42
scribe resolve
scribe status
scribe submit -m "Integrate development through change 42"Start with no opened files or unfinished sync. The planner reads the complete source delta, target states, rename ancestry and collision metadata, subject to its existing bounded planning limits. It never filters the integration delta to only selected files. The server still validates full coverage, target head, permissions, repository-wide locks and configuration rules before acceptance.
Files outside the view
If a result can be chosen by accepted content identity and mode (one side is unchanged, or both sides agree), the client records the decision without fetching file content or creating a local file. This covers additions, edits, deletions, and unambiguous renames, including renames across the view boundary. Submission reuses the accepted manifests. Required locks are still acquired even for excluded paths; an existing foreign lock blocks the integration.
Excluded paths get neither local baselines nor opened records. Untracked bytes
at those paths are never read, submitted, overwritten, or removed by integration.
scribe resolve and scribe status mark these decisions as outside view;
JSON exposes outside_view. The macOS and Windows apps show an Outside View
badge in the resolution panel and "Conflict · Outside View" or "Resolved ·
Outside View" in the file list, and offer no version choice for such a path
until the view includes it. Use the resolution report for the complete plan,
including excluded decisions, and inspect included file contents in your editor.
Include conflicts explicitly
For example, your view includes Source and Config, while both the current
branch and development changed Art/Characters/hero.asset after their common
ancestor. That asset participates in the merge even though you have no local
copy. If only the source changed it, or both sides now agree, its accepted result
can be reused without a download. Edit-versus-delete and competing destination
names can also require an excluded path to be included.
When identity alone cannot decide an excluded path, the client reports a conflict without downloading its content, even if text merging could resolve it. Expanding the saved plan keeps that conflict explicit; export its inputs for a text merge or choose a side. Content conflicts, competing renames and path collisions block submission. An explicit ours/theirs choice cannot bypass the inclusion requirement.
--all selects every path in the plan, including excluded ones; it cannot be
used to bypass inclusion. Name specific included paths to resolve those alone.
Expand the view while the integration is active. Completed choices and manual edits stay intact; the source, target and integration base stay pinned:
scribe workspace view add Art/Characters/hero.asset
scribe resolve --theirs Art/Characters/hero.asset
scribe submit -m "Integrate development with the reviewed asset"For rename/collision groups, include every reported member, including deleted or
renamed spellings, before choosing the group. Other excluded assets stay excluded.
Expansion uses the saved target revision for newly included files. Resolved
paths install their saved result directly, without downloading an intermediate
target copy; unresolved paths receive their target version for editing. Newly included unresolved rows
remain explicit conflicts: use --ours, --theirs, or edit and accept --working;
--export supplies the saved inputs for external tools. Expansion never reruns
planning or text merging over completed work.
The same commands work during cherry-pick. view set can also broaden a selection,
including --all or a profile read at the pinned target. Removing any existing
inclusion is refused until the integration finishes or is aborted. Ordinary stale
file resolution (resolve --update) must finish before its view can change.
Files that expansion must replace are retained with an index in .scribe/_state/recovery.
Already included files, baselines and opened records are left alone. Mounted
repositories retain their own local-work and pinned-revision checks.
Recovery and target changes
The complete plan is persisted before file application. merge --continue or
cherry-pick --continue resumes it at the pinned revisions. Excluded decisions
are kept in that same journal. The exact final changeset and operation ID are
persisted before submission, including excluded paths; a lost reply is resolved
through ordinary submit recovery without generating a new operation ID. Successful
finalization updates baselines only for included paths.
An interrupted expansion retains its pending view intent. Run scribe sync to
resume it, or scribe workspace view --abort to return to the previous selection.
Resolution choices and submission are fenced until that transition completes.
If the view was already published when the process stopped, use
scribe resolve --continue (or the merge/cherry-pick continue command). Previously excluded
choices become ordinary local opened changes through the existing durable
resolution application. Submission waits for those choices to finish applying.
Cancelling the view preserves recovery copies and the original integration plan;
to abandon that plan too, cancel the view first, then abort the integration. If
repository restoration interrupts expansion, abort first to archive the obsolete
plan, then cancel the pending view and sync the restored repository.
If the target advances before acceptance, the server rejects the stale merge.
Resolve any unknown submission outcome first. For a partial-view integration,
resolve --update then directs you to abort and restart against the new target;
it does not discard or reinterpret excluded decisions. Expanding a view does not
update an integration to a newer target revision.
SDK and web
Workspace views live in the native working copy. The SDK and web merge/cherry-pick planners already operate on accepted server state without a local checkout, so this change needs no new wire/HTTP operation or web selection control. Web history shows the resulting ordinary merge or cherry-pick, with its normal provenance. The web planners retain their own path-count, conflict-editor and rename limits; those limits are independent of native workspace views.