Add workflow modes, structured workspace operations, service management hardening, and OAuth persistence fixes

[tao-xiaoxin]

Summary

This PR has expanded beyond the original description.

Compared with the current Waishnav/devspace main, this branch now adds the workflow, service-management, and OAuth/runtime changes from my fork, while also incorporating the latest upstream README updates.

Main additions in this PR:

• Add Codex-style workspace collaboration flows:

  • workflow modes: default / plan
  • plan workflow handling via /plan
  • goal lifecycle handling via /goal, create_goal, get_goal, and update_goal
  • exact goal metrics support
  • compact pending-input answer handling for structured user-input flows (for example, 1B, 2A)

• Add bundled system workflow skills under skills/.system:

  • workflow
  • plan
  • goal
  • architecture review
  • skill authoring

• Add structured workspace operations for host-safety-sensitive flows:

  • apply_workspace_patch for coordinated multi-file patch application
  • git_push for explicit structured push requests instead of routing pushes through raw shell
  • command annotations for config, workspace, service, and skills flows

• Improve local config and service lifecycle management:

  • local config operations
  • service management commands
  • isolated service config path handling
  • simplified service command flow
  • rename service uninstall to service remove
  • broaden Linux service manager detection
  • harden service entrypoints and config environment handling

• Improve OAuth/runtime compatibility:

  • persist OAuth clients across restarts
  • persist refresh token hashes and access token hashes across restarts
  • persist approved consent records across restarts
  • improve OpenID discovery compatibility
  • register discovery routes in a safer order
  • preserve original request paths in logs
  • expose OpenAI widget template metadata
  • add opt-in tunnel mode and shell execution policy

• Docs and test updates:

  • add Chinese README
  • add plan / goal usage documentation
  • clarify strict skill install targets
  • make CLI skills tests avoid hardcoded local paths
  • sync bundled system skill versions with the package

Motivation

This PR is aimed at improving how DevSpace supports Codex-style collaborative coding workflows in MCP clients.

The goal is not to bypass host safety. The goal is to expose more explicit, workspace-scoped, auditable MCP tools and workflow primitives so clients do not need to rely on generic shell commands for batch writes, planning, long-lived goals, or git push operations.

It also improves the managed service and local configuration flow so DevSpace behaves more predictably across restarts and across different host environments.

Usage

This PR is meant to improve how DevSpace is used from ChatGPT or another MCP host, especially for planning, durable goals, safer workspace edits, and managed background service flows.

1. Start DevSpace and register workspaces

Install and initialize DevSpace:

npm install -g @waishnav/devspace
devspace init

Add one or more allowed workspaces:

devspace workspace add ~/workspace/project-a --default
devspace workspace add ~/workspace/project-b
devspace workspace list

If you want DevSpace to run as a managed background service:

devspace service start
devspace service status
devspace service logs

2. Open a workspace from the MCP client

From ChatGPT or another MCP-capable client, call:

• open_workspace

once per project folder or worktree, then reuse the returned workspaceId for later file, search, edit, shell, plan, and goal operations.

3. Use workflow aliases for planning and durable goals

This PR adds stable workflow aliases:

• /plan
• /goal

Typical examples:

@devspace /plan Add a hello CLI command that prints "Hello DevSpace".
@devspace /goal Create a durable Goal to ship a cross-platform service restart flow.

/plan is for repository inspection first, then saving a durable implementation plan.

/goal is for keeping a longer-lived project objective across sessions.

4. Use structured workspace tools instead of generic shell where possible

For multi-file or safety-sensitive operations, the new flow prefers structured MCP tools over raw shell commands:

• apply_workspace_patch for coordinated multi-file edits
• git_push for explicit push requests
• resolve_skill for loading Skill instructions
• get_goal, create_goal, update_goal for durable goal state

This makes changes more auditable and reduces cases where host safety blocks broad shell-based write or push operations.

5. Service and config workflow

This PR also improves the managed service flow. Typical commands are:

devspace config show
devspace service start
devspace service restart
devspace service status
devspace service doctor
devspace service remove

Configuration changes persist locally, and managed service flows are intended to be explicit and cross-platform rather than ad hoc system setup.

What Changed Since The Original PR Description

The original PR description covered the early workflow support and OAuth reconnect-related fixes.

The branch now also includes:

• service lifecycle and config hardening
• bundled skills/.system packaging
• exact goal metrics support
• additional docs and test updates
• the latest upstream README merge

So this PR is now broader than the initial workflow-oriented summary.

Tests

- `npm run typecheck`
- `npm test`
- `npm run build`

[Waishnav]

Thanks for this huge PR. You should have splitted this into small stacked PRs. There are few ideas which i really liked but few i did not follow

1. goals feature just like codex, but in devspace only limiting factor is that we can't control chatgpt as harness, we don't' have access to their auto compaction and any other hook which we can utilize and add bring the goal of that session into the model's context. so only workaround to this is relying on get_goal tool call with prompting
2. devspace system skills for various workflows like code review and planning inside chatgpt and handing over that plan to local agent for execution (codex, claude code, opencode, pi etc)
3. current devspace is basically default tools from pi sdk, i'm current thinking of moving away from it to make it more similar to codex's tools like apply_patch, write_strin. exec_command etc, if you want to experiment you can try this PR feat: add Codex-style tool mode #26
4. git_push tool is unnecessarily expose to model since we already have bash tool but it make sense because of openai's security layer blocks that tool call sometimes, but i don't think this should be expose to model, i might be adding it as app only tool and having that action button in the open workspace UI
5. currently skills are loaded using read tool, and it is best way imo, cause it avoids adding extra unnecessary tools in models memory, it keeps things simple and minimal from models' POV. So your implementation sucks, tho good ideas to experiment. but my philosophy is basically having minimal tools expose to models

Hope you understands the philosophy for later PRs and future contributions. Also before raising PR do create a issue and lets have brief discussion around these features. that way you could save your tokens :)