Private repository workflow

Current status: partial private ingress, custody, and sealed-result foundations. Reviewed local Git snapshots, sealed-descriptor import, durable primary-source binding, private reconstruction, and exact-Run worktree-result custody have local tests. Wall cannot yet attest a protected source Run on Virtus. Final worktree bytes and modes are distinct from Cell-local Git index or commits, which are not retained. Result selection, host apply, commit, and push remain unavailable.

Private repository ingress

A broker authenticates outside the Cell and stores verified content-addressed Git objects. Each candidate receives an exclusive writable worktree from a pinned immutable base. Secrets and unsafe filesystem objects are blocked before import; host repositories are never live mounts.

Requirements cover submodules, LFS, monorepos, sparse paths, and declared generated inputs. Dirty local state requires an explicit previewed import with provenance. A remote import is a typed Connection-backed read and rejects embedded credentials.

Policy may admit multiple named Repository Objects. Each retains its own identity, ingress manifest, policy, delivery scope, and evidence. Import updates pending desired state; it does not hot-copy into an admitted generation or synchronize continuously with the host.

Selected delivery

A candidate returns patch, commits, changed paths, artifacts, checks, evidence gaps, and an exact digest. Only the deliberately selected sealed result can leave. Previewed three-way local apply refuses unresolved conflicts. An external GitHub proposal is a governed Effect, keeping credentials outside the Cell. Deleting a private candidate must not corrupt shared immutable repository objects.

Example: the agent edits a private copy while the developer's checkout stays independent. The developer reviews and applies the selected result explicitly.

See repository requirements and governed effect flow.