Repository navigation
Make SlipJay workspaces first-class in T3 with a Jujutsu driver #21
Description
Outcome
A thread working in a SlipJay (Jujutsu) workspace gets the same core T3 experience as a Git checkout: file and change review, per-turn diffs and restore, clear workspace status, and governed landing through SlipJay.
Verified starting point — 15 October 2026
The repository detection/file-review slice is delivered in #22, landed as d7843f8. The current integration revision inspected for this plan is b725c10. Its JjVcsDriver implements detection, file listing, ignore filtering, remotes and review diffs, including colocated repositories. Do not rebuild that slice.
Remaining source gaps: JjVcsDriver has no checkpoint operations; CheckpointStore already delegates operations through the selected driver's optional checkpoints contract, but its eligibility probe still explicitly detects Git. Source landing does not establish installation or running-client acceptance.
Conceptual model and settled constraints
T3 owns the thread, interaction and per-turn recovery history. Jujutsu owns repository identity, working-copy snapshots, diffs and workspace/base status. SlipJay owns workspace allocation and the governed landing operation. Keep each responsibility behind the existing VCS driver, workspace-provider and service contracts; no second version-control or landing system.
- SlipJay is not a VCS driver. The driver is Jujutsu; SlipJay remains the workspace provider selected by slipjay.json. No second opt-in setting.
- Colocated repositories containing both .jj and .git use Jujutsu. Henry accepted the resulting main-checkout strip change on 15 October.
- Settings shows SlipJay as a detail of Jujutsu and a read-only workspace-provider line in project defaults, using the existing provider decision.
- Plain Git projects retain their existing workflow.
Remaining delivery plan
Per-turn recovery
Extend the existing Jujutsu driver with checkpoint operations and make checkpoint eligibility depend on the selected driver's support. Preserve the existing checkpoint service, ownership/restore safety and storage concepts.
A checkpoint identifies an exact retained snapshot, so later Jujutsu rewrites cannot silently change the turn's recorded content. Prove the retention mechanism against Jujutsu garbage collection and abandoned-change cleanup before relying on it. Include authored-path accounting and reference cleanup, not capture alone.
Automatic thread allocation
Use the existing launch/preparation and workspace-provider services. A top-level SlipJay thread obtains one workspace on the selected host before its first provider turn, regardless of whether that turn is read-only or implementation. Preserve its binding thereafter; idempotent retries must not allocate twice. A workspace is a stable execution location, not edit authorisation.
Read-only managed children inherit the exact parent host and checkout with equal or narrower permissions and allocate nothing. Concurrent writer children retain separate assigned workspaces and explicit handoff/source semantics. Never run setup or allocate another workspace just to launch a reader. Cancellation, failure and deletion clean up only allocations owned by that operation and preserve borrowed/unfinished work. Git-only defaults are unchanged. This supersedes the draft picker/New workspace requirement and the previously discussed lazy exploration-to-editing transition.
Workspace context
Use the existing VCS status contract for Jujutsu status and SlipJay allocation metadata for workspace/Issue identity. Read the integration bookmark from slipjay.json. Keep one provider decision for Settings and the composer.
Retain the owner-approved composer behavior: workspace and optional Issue on the left; base, behind count and changed-file count on the right. The owner revised allocation on 15 October: choosing the project and host is sufficient. An empty draft allocates nothing; its first submitted message automatically obtains a SlipJay workspace before the provider starts, including question-only threads. The same workspace is retained across turns, retries and restarts; started threads show a locked identity. No manual workspace selection is required. The root reads as the integration bookmark plus “(root)”. The strip stays visible for SlipJay threads.
Observing a landing
Consume the installed CLI's slipjay watch --json stream through one shared service per host, matching repository and workspace change identity. An agent-started landing and a T3-started landing produce the same observed state.
Use snapshots as the authoritative current state, with the CLI's bounded replay/cursor behavior for reconnect. Do not assume unlimited event history or infer success from missing events. Show disconnection honestly and reconcile against the new snapshot. T3 holds no runner credentials or SSH forward of its own.
The approved strip shows Landing plus the reported stage, then Landed plus the published commit or Land failed plus the reported stage/message. Open retained operation logs through slipjay runner log without a shell.
Starting a landing
Expose Land through the existing service/command and permission paths for SlipJay projects. Invoke the installed slipjay land from the exact thread workspace; use the same status observer above. Check the installed CLI's structured output before designing result parsing. Link a reported pull request to the thread.
SlipJay remains responsible for gates and publication. T3 must not bypass gates, move integration/release bookmarks itself, automatically retry a failed land or claim a cancelled observer cancelled the runner operation. A failure must preserve recoverable work; report any state SlipJay actually changed rather than promising an unchanged checkout.
Acceptance and delivery evidence
- In a JJ-only workspace, a real turn produces the correct per-turn diff and can be restored through the existing safety rules. The checkpoint survives tested cleanup; colocated and Git-only cases retain their expected behavior.
- Workspace identity, Issue, integration base, behind count and changed paths are correct and refresh after edits or integration movement. Selecting another host resolves that host's workspace.
- A landing started outside T3 appears in the correct thread; T3's Land action follows the same operation. Successful, failed, disconnected and reconnected states are truthful; logs identify the same operation. Concurrent workspaces cannot display each other's landing.
- Web and desktop expose the approved interaction; mobile uses shared contracts/services and keeps any existing corresponding diff/restore paths working. Explicitly record which controls apply on each surface rather than assuming web coverage proves mobile.
- Agent/service access and remote/relay use the destination environment's workspace and permissions. No direct local-path assumption or duplicate landing implementation in transport handlers.
- Focused driver/checkpoint/status/watch/service tests cover meaningful behavior and Git regression cases. Review committed Tickets and the completed Spec before governed landing as required.
- Final acceptance includes an isolated, populated client pass when authorized, plus installation/runtime evidence before claiming the installed app supports it. Landing, installation and rendered acceptance are separate completion claims.
Native sub-issues and blocked-by edges own the delivery sequence. The existing slices remain the implementation units; this plan creates no duplicate tickets.
Non-goals
Jujutsu history editing from T3 (describe, squash, push), conflict UI, pull requests from Jujutsu outside SlipJay, runner administration, release promotion, or a new provider/configuration authority.
Activity
pechhe commentedon Oct 15, 2026
Implementation checkpoint — non-UI work only, inline as requested (no implementation subagents).
Assigned workspace:
/Users/henrypetch/.slipjay/workspaces/t3-21. Candidatee24d491e66a486e9518c00d98a82910e90f3c4c6, basef51c88547155aa334da386954236351111c8b657on integrationt3peach.Implemented: automatic SlipJay allocation for a normal top-level launch's first message; empty root drafts allocate/run no setup; managed children retain their exact supplied source and permission binding; branchless allocation reuse after setup failure/retry. Jujutsu checkpoint capture, retained hidden refs, diff, authored-path filtering shared with Git, restore through a private temporary index, ref cleanup and driver-capability eligibility. Jujutsu status now serves integration bookmark, changed-file statistics and behind count through the existing workflow/broadcaster path, preserving Git action guards. Status asks JJ for structured line statistics, not full patches.
Checks on the candidate: 130 tests passed in the five focused launch/workspace/managed-agent/restore-safety/rollback files; 48 passed across JJ driver/workflow/status broadcaster; 95 passed across JJ driver/checkpoint store/Git driver/checkpoint service/capture. Suites overlap; these are run counts, not a unique total. Server typecheck passed; 14-file format check passed. Scoped lint passed with one pre-existing warning on an untouched ThreadLaunchService.test.ts line. Retention test abandons the JJ change and old operation history, runs
jj util gc --expire now, then restores the retained content. Shared-workspace test confirms restore leaves peer files and the shared Git index untouched. A disposable nested-directory probe also confirmed restore stays within that directory.NOT landed, installed, deployed, independently reviewed or client-accepted. #21 remains partial: composer presentation, workspace/Issue metadata, landing observer/outcome reconciliation, Land command and surface acceptance remain. UI is held under the shared model policy while Henry waits for Claude subscription refresh; the instruction against subagents remains in effect. Earlier source-map planning helper auto-resumed through T3's limit handling; its old task was closed to prevent more follow-ups. No new implementation child was started.
#30 acceptance now records the observed CLI constraint: queue snapshots omit terminal landings, so a missing known operation needs
slipjay runner outcome <operation>reconciliation; absence alone is not a terminal result.feat: Jujutsu checkpoints, automatic SlipJay workspaces and the works…
pechhe commentedon Oct 15, 2026
Progress: 6687378 landed automatic SlipJay allocation at launch, Jujutsu checkpoints (#23, closed) and the workspace strip (#29, closed); review answered before landing. Remaining: #30 landing progress, #24 Land action. Gap found:
t3_worktree_handofffails in a Jujutsu/SlipJay project ("Project workspace … is not a git repository"), so a thread bound to the main checkout can't move into a SlipJay workspace; mobile still shows Jujutsu checkouts as "Not a repo".pechhe commentedon Oct 15, 2026
#30 landed (6d12740), reviewed by Sonnet; the blocking finding and all should-fix findings were answered before landing.
any. The pull request RPCs now have their own group (WsPullRequestRpcGroup) and handler layer, withWsRpcGroupas the merged whole.slipjay landwatched in a real client, and a UI pass.blob:nonepartial clone, and jj cannot lazily fetch missing blobs. Fetching them withgit cat-fileand then runningjj workspace update-stalefixed it.Next: #24 (the Land action).
pechhe commentedon Oct 15, 2026
#24 landed (30eeaa8), reviewed by Sonnet; both blocking and all four should-fix findings were fixed before landing.
failed at …,followed an older commit,Kept landed workspace …). The gate output tail is not used.slipjay landreports none.slipjay landremoves the landed workspace during housekeeping, so the thread's worktree path disappears after a successful Land. How a thread should behave after its workspace is released is not decided yet.5 remaining items
pechhe commentedon Oct 15, 2026
#41 landed (4221a5a): one owner for SlipJay project rules. Sonnet ticket review: 0 blocking, 3 should-fix (all addressed: always a reason for an unpublished Land, allocate from the SlipJay root, no non-null assertion). Remaining: #42, #43, #44.
pechhe commentedon Oct 15, 2026
#42 landed (14c9c0c): landing changes refresh only checkouts of their repository. Sonnet ticket review: approve, 0 findings. Remaining: #43, #44.
pechhe commentedon Oct 15, 2026
#43 landed (a500504): mobile shows Jujutsu checkouts. Sonnet ticket review: 0 blocking, 2 should-fix (both fixed: hide Pull latest for Jujutsu, matrix label). Remaining: #44.
Version-control controls per surface (after #43)
Desktop wraps the web client, so it matches web.
Gaps recorded, not addressed here: mobile has no Land or landing log; web offers no branch strip for a plain Jujutsu checkout, and the thread panel's "open changes" needs a Git repository.
pechhe commentedon Oct 15, 2026
#44 landed (c80c7f0): user docs for Jujutsu checkouts, SlipJay workspaces, the strip and Land; Settings Workspaces text per provider. All Tickets of this Spec (#22, #23, #24, #29, #30, #41–#46) have landed.
pechhe commentedon Oct 15, 2026
Delivered: SlipJay workspaces are first-class in T3 (Jujutsu detection and checkpoints, per-thread workspaces, composer strip with landing state, Land, review follow-ups #41–#46).
pechhe commentedon Oct 15, 2026
Final Spec review
spec-reviewer, read-only.Standards (0 blocking, 3 should-fix)
slipjaystderr inGitCommandError.detail, cause dropped → SlipJay errors keep their cause and carry no raw CLI output #51baseRefinserted unquoted into a revset in the Jujutsu review path → Quote the review base ref as a revset symbol in the Jujutsu driver #52Spec (1 blocking, 1 should-fix)
slipjay landreports none: it publishes to the integration branch, and its README has no pull-request output.Evidence gaps the reviewer named
#21 is reopened until #50–#53 land.
pechhe commentedon Oct 15, 2026
Follow-ups from the final Spec review: #52 and #53 landed in e8737ce, #50 in 9f4e954, #51 in 28263f7, each after a clean ticket review. #50 depends on pechhe/slipjay#72 (
slipjay landed <path>), which is implemented but not yet landed or released, so #50 and this Spec stay open until it is.pechhe commentedon Oct 15, 2026
All follow-ups from the final Spec review have landed: #52 and #53 in e8737ce, #50 in 9f4e954 (with SlipJay v3.19.0), #51 in 28263f7, each after a ticket review.