Skip to content

feat(workspace): make a saved Space shareable across machines - #1194

Closed
Rushikeshiitb wants to merge 1 commit into
risa-labs-inc:mainfrom
Rushikeshiitb:feat/workspace-portability
Closed

Rushikeshiitb wants to merge 1 commit into
risa-labs-inc:mainfrom
Rushikeshiitb:feat/workspace-portability

Conversation

@Rushikeshiitb

Copy link
Copy Markdown
Contributor

Description

Makes a saved Space shareable across machines. A materialised Space records the absolute project path of the machine it was built on - in projectPath and in every tab's workingDirectory / filePath / url, and shell-quoted inside initialCommand - so exported verbatim it points at a directory that exists on no one else's machine. This adds a project-relative form (using the same {projectPath} placeholder PredefinedWorkspaces templates already use) and exposes the transform through the MCP registry.

🔄 Type of Change

  • ✨ New feature (non-breaking change that adds functionality)

📦 Version Impact

  • Minor version (new features, enhancements) - x.+1.0

✅ Testing Checklist

🧪 Local Testing

  • I have tested this change locally on my development machine
  • All existing tests pass with my changes
  • I have added new tests for new functionality
  • I have verified the fix/feature works as intended

🖥️ Platform Testing

  • 🍎 macOS - Tested and working

🏗️ Build Verification

  • Project builds successfully with my changes (:composeApp:compileKotlinDesktop, :composeApp:desktopTest)
  • No new build warnings introduced
  • ./gradlew :composeApp:ktlintCheck :composeApp:detekt pass

🔍 Code Quality

  • My code follows the project's style guidelines
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • My changes generate no new warnings or errors

📝 Additional Context

🎯 Motivation and Context

exportWorkspace / importWorkspace already round-trip a Space through JSON, but the JSON carries machine-specific absolute paths, so a Space shared with a teammate (or moved to another machine) opens tabs and terminals pointed at paths that do not exist. This adds the missing project-relative form so a Space can actually be shared, without changing the existing export/import behaviour.

🧠 Implementation Details

  • WorkspacePortability.toPortable walks the split tree and replaces the Space's own project path with {projectPath} in url / filePath / workingDirectory (raw) and in initialCommand (matching the shell-quoted form first, then the raw form - the exact inverse of WorkspacePlaceholders.substituteProjectPath with quote = true), and clears projectPath. A Space with no project path is already portable and is returned unchanged.
  • WorkspacePortability.fromPortable substitutes a chosen project path back in through the very same WorkspacePlaceholders.substituteProjectPath the host uses when materialising a template - raw for path fields, shell-quoted for commands - so a round trip to the same path reproduces the original tabs. It mints a fresh id (LayoutWorkspace.generateId()) so importing a shared Space cannot collide with, or overwrite, a Space already on this machine.
  • The split-tree walk preserves the tree shape and every non-path field (it rebuilds only the tab fields via copy).
  • WorkspacePortabilityMcpToolProvider exposes workspace_make_portable and workspace_resolve_portable, both readOnly = true pure transforms over the serialized Space JSON that touch no host state. Saving or opening the result stays with the existing create_workspace / open_workspace tools, so this is a transform surface rather than a second write path.
  • Registered beside WorkspaceMcpToolProvider in McpToolRegistryImpl.

⚠️ Breaking Changes

None. The existing exportWorkspace / importWorkspace and the LayoutWorkspace type are unchanged; this is a new, additive utility plus two read-only MCP tools.

👀 Review Focus Areas

  • Logic and Algorithm: the parameterize/resolve inverse pair, especially the shell-quoted command path
  • Platform Compatibility: command quoting goes through CommandProcessor.quotePath (POSIX/PowerShell), same as the template path

Test coverage

  • WorkspacePortabilityTest (6 tests): placeholder replacement + projectPath cleared, faithful round trip to the same path, binding to a new path with a fresh id, no-project passthrough (same instance), invalid-JSON returns null, serialize/deserialize round trip.
  • WorkspacePortabilityMcpToolProviderTest (4 tests): both tools read-only, make-then-resolve across machines, invalid/missing input errors for each tool.

A materialised Space records the absolute project path of the machine it was
built on - in its projectPath and in every tab's workingDirectory / filePath /
url, and shell-quoted in initialCommand - so exported verbatim it points at a
directory that exists on no other machine.

- WorkspacePortability.toPortable rewrites the Space's own project path to the
  {projectPath} placeholder (the same token PredefinedWorkspaces templates use),
  clearing projectPath; fromPortable substitutes a chosen project path back in,
  reusing WorkspacePlaceholders.substituteProjectPath so the substitution - raw
  for path fields, shell-quoted for commands - is exactly the one the host uses
  when materialising a template, making a round trip faithful. Import mints a
  fresh id so a shared Space cannot collide with or overwrite a local one.
- WorkspacePortabilityMcpToolProvider exposes workspace_make_portable and
  workspace_resolve_portable, both readOnly = true pure transforms over the
  serialized Space JSON (no host state), so an agent can produce a shareable
  Space or bind a shared one to a local project; saving/opening stays with the
  existing create_workspace / open_workspace tools.
- Registered beside WorkspaceMcpToolProvider in McpToolRegistryImpl.

Covered by WorkspacePortabilityTest (round-trip to the same and to a new project
path, placeholder replacement, no-project passthrough, invalid JSON) and
WorkspacePortabilityMcpToolProviderTest (each tool through its handler).
@kshivang

Copy link
Copy Markdown
Contributor

Thank you @Rushikeshiitb — this feature is legitimate and the implementation/tests passed focused validation. I reviewed it together with #1195 against current ; the only shared integration point was , and both registrations were retained.\n\nTo keep integration dev-targeted and preserve your authorship, I carried your original commit into consolidated PR #1506 (the commit remains separately authored by Rushikesh): https://github.com/risa-labs-inc/BossConsole/pull/1506\n\nI’m closing #1194 as superseded by #1506. No code credit is being dropped.

@kshivang

Copy link
Copy Markdown
Contributor

Superseded by consolidated dev-targeted PR #1506; contributor credit is preserved in the carried commit.

@kshivang

Copy link
Copy Markdown
Contributor

Correction to the handoff above: reviewed against current origin/dev; McpToolRegistryImpl was the only shared file, and both provider registrations were retained in consolidated PR #1506. Rushikesh authored commit 2ee0e91 there; no contributor credit was dropped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants