feat(workplace): per-project custom working directory

[CatJuly]

Summary

Every project's workplace is currently pinned to ../OpenOPC_workplace/<project_id>/ beside the OpenOPC repo, with no way to relocate it. In practice most users want agents to work inside an existing repository (their actual codebase), not in a freshly created empty folder. Today the only workarounds are symlinks or spelling out the path in every prompt.

This PR makes the workplace configurable per project, end to end: the path a user sets is the cwd the execution agent (claude_code / codex / cursor / opencode) is spawned with.

Design

Resolution is three-tiered, most specific first:

1. Per-project path — stored in a new project_config table inside that project's own tasks.db
2. $OPC_WORKPLACE_ROOT — global override; each project resolves to $OPC_WORKPLACE_ROOT/<project_id>
3. Default — the existing ../OpenOPC_workplace/<project_id>/ layout, unchanged

get_project_workplace() gains an optional custom_path parameter; callers without DB access (tests, preflight) keep the old behaviour untouched. The DDL is idempotent and runs on every store initialize(), so existing databases gain the table with no migration step. The engine loads the custom path into a synchronous cache during initialize(), keeping the existing sync resolvers' signatures unchanged.

Sticky session workspace roots that merely equal the project workplace are no longer persisted into execution_defaults — they carry no session-specific intent and previously froze the session to whatever the workplace was at first message, so later set-workplace changes never took effect. Sessions pinned before this rule self-heal on their next message. Roots derived from an explicit output dir keep sticking exactly as before (covered by tests/test_engine_session_defaults.py).

Surfaces

Office UI

• Create dialog: + opens a centered modal (same conventions as the delete-confirm / org-create dialogs) with project name and an optional workplace path. The name field validates live and previews the derived slug.
• Settings: a gear button next to the project selector shows the resolved path and its source tier (custom / env / default), pre-fills custom paths for editing, and offers reset-to-default.
• All dialogs use theme tokens, so the paper theme stays readable.

CLI

opc project set-workplace myapp --path /path/to/existing/repo [--create]
opc project show-workplace myapp
opc project reset-workplace myapp

Docs: README / README.zh-CN document the resolution order and commands.

Testing

• End to end: created a project pointed at an existing repository and ran a claude_code task — the agent reports cwd inside that repository (verified against a real session, including one that had been pinned to the old default and self-healed).
• set-workplace → show-workplace → reset-workplace round-trips through the project DB; a legacy DB (pre-existing tables, no project_config) upgrades in place with data intact.
• pytest failure set is identical to current main baseline (no new failures); tests/test_engine_session_defaults.py passes 7/7.
• Frontend npm run typecheck and npm run build clean; rebuilt frontend_dist included.

Stacked on #31

This branch is based on #31 (fix/project-create-name-feedback) because both touch ProjectSelector.tsx — the create-dialog rewrite here supersedes the inline validation added there. Until #31 merges, its commit (d7cfb2b) appears in this PR's diff; once #31 lands, this PR reduces to its own two commits. Merging #31 first is recommended.

[LZH-YS1998]

Request changes: establish one theme source of truth and add regression coverage

The implementation direction is sound: the selected Office UI theme is restored from localStorage, invalid stored values fall back safely, and storage failures do not prevent the application from rendering. The change is isolated from the task engine and does not introduce a direct work-order progression risk.

I am requesting changes before merge for the following maintainability and regression-safety issues:

1. Use a single canonical theme registry

Theme identity is currently represented independently by the ThemeName union, the THEME_NAMES validation list, the theme selector options, and generated CSS class names. These parallel declarations can drift. For example, a newly selectable theme could be persisted successfully but rejected after reload, or a valid stored theme could lack a matching visual implementation.

Please define one canonical, immutable theme registry and derive the following from it:

• the ThemeName type;
• validation;
• selector options;
• the default theme; and
• the applied DOM theme identifier.

The CSS should consume the same stable identifier contract rather than requiring another independently maintained list. This should replace the duplicated declarations, not add another synchronization layer.

2. Add focused automated regression tests

Please add tests covering:

• the default theme when no preference exists;
• restoration of every registered theme;
• persistence when the user changes themes;
• fallback from an unknown or obsolete stored value;
• safe behavior when localStorage.getItem or localStorage.setItem throws; and
• consistency between the canonical registry, rendered selector options, and the DOM theme identifier.

The tests should exercise public behavior and avoid duplicating the implementation’s theme list in test code.

3. Rebuild the frontend artifact after integration

PRs #31 and #33 both replace the hashed frontend bundle and modify frontend_dist/index.html. After integrating the source changes, regenerate frontend_dist once from the combined source tree and verify that the committed entry point references the newly generated bundle.

Do not resolve the generated-file conflict by selecting either PR’s existing artifact.

With these changes, the feature will be safe to merge and substantially less likely to regress during future theme additions or refactoring.