Projects and workspaces

Projects group conversations that use the same codebase. A project can map to folders on one or more execution devices.

Existing folders and Git projects

When the project list is empty, the sidebar's Projects section shows + New project directly. Select it to choose a Local project or Cloud project; cloud projects still require a cloud connection. Wework hides this empty-state action while project data is synchronizing so an unfinished load is not mistaken for an empty list.

Choose Use existing folder for code already on the device. Confirming creation saves a distinct project; multiple projects can share the same source folder. Select an existing project from the project list instead of creating it again. Registered projects remain in the project list after refresh or restart, including when their source folders are inside a Codex directory.

In local mode, choose Local project and select one or more folders in the system directory picker. This entry always uses the local execution device, even when cloud or remote devices are connected. To use another device, choose Cloud project, then open an existing directory, create a blank project, or enter a Git repository URL to clone on the target device. Git projects use the repository name as the directory name by default and allow an optional branch and target parent directory. After submission, the dialog closes immediately and the project list shows clone progress; failed clones can be retried or dismissed there.

In the cloud-project creation dialog, Use existing folder and Create also open the system directory picker when the selected execution device is the current Wework machine. Cloud and remote devices continue to use the in-app directory picker because their directories must be read and created by the selected device. Desktop automation keeps the controllable in-app picker so CI can verify the flow reliably; ordinary Wework sessions do not use that automation compatibility path.

The local create-project dialog uses the first source folder's name as the project name by default; you can edit the name or add and remove source folders before confirming. Wework saves the folders as one Codex project and uses the first folder as its default workspace. The project list keeps one project row instead of expanding every source folder. Use Edit project from the project menu to rename the project, add or remove source folders, or change the primary folder. Multi-folder creation currently applies only to local Codex projects; cloud and remote projects are still added one folder at a time.

If a connected cloud device and the current local Wework executor refer to the same workspace, adding that folder as a local project merges the local and cloud records into one project row. Wework matches the executor identity, normalized workspace path, workspace kind, and worktree. The project remains deduplicated after Wework restarts, and existing cloud tasks continue to appear under the merged project.

To create a Git project, select a device, repository, default branch, and destination. If repositories are unavailable, check the Git connection and token permissions in Settings.

Select and create branches

Use the branch menu in the composer to search and switch local branches, or create and check out a new branch. The list excludes tags and remote-tracking refs and places the current local branch first. Branch listing and current-branch queries use commands compatible with older Git versions, without depending on git branch --format or --show-current. A detached HEAD has an empty current branch name; local branches remain selectable.

Selecting a branch performs checkout on the execution device even when its name matches the last displayed branch, so cached UI state cannot prevent recovery from detached HEAD.

Pushing also uses a current-branch query compatible with older Git versions. Check out a branch before pushing from a detached HEAD.

If another device still reports unknown option, confirm that its Wework executor has been updated. Cloud connections to cloud or remote devices also require an updated Wegent Backend. Git queries run on the device that owns the workspace; updating Git on another machine does not change that device's queries.

View pull request and merge request status

When a task is opened or selected, Wework reads the branch, remote URL, PR/MR status, and change counts concurrently. It displays the PR/MR status as soon as that lookup finishes instead of waiting for a slower diff count; changed-file and line counts update independently afterward. These Git queries do not start the user's login shell, so shell startup scripts, SDK initialization, and other personal environment configuration cannot block the environment panel.

During a manual environment refresh, Wework keeps the previous change statistics for the same device and workspace until the new diff statistics are ready. Intermediate branch or PR/MR results therefore do not briefly reset the counts to zero. Switching to another device or workspace does not reuse the old statistics.

For tasks using a GitHub or GitLab workspace, the environment panel looks up the pull request (PR) or merge request (MR) associated with the current branch. The request number and title stay on one line. The main icon color communicates the open, closed, or other request state, while a small lower-right icon shows checks pending, passed, or failed. A red merge-conflict icon takes priority over the check result when conflicts exist. After a GitHub PR enters the merge queue, Wework shows a yellow In merge queue waiting icon even when all branch checks have passed, until the PR leaves the queue or is merged. When a new commit is pushed to the same PR after a Merge Queue failure, Wework ignores historical failure events older than the current head commit and shows the new commit's check status. When a GitHub workflow check has multiple runs, Wework uses the latest result so a superseded cancelled or failed run does not override the current status. Select the status icon to open its action menu. Selecting outside the menu, pressing Esc, or choosing an action closes it. Choose Open PR/MR to open the request in your browser.

The task list in the left sidebar, project-space board, and right-side environment panel reuse the same PR/MR monitoring snapshot, status priority, and icon for a task. Failed checks, merge conflicts, Merge Queue states, drafts, closed requests, and merged requests update consistently in all three places. The environment panel also stops showing an old PR/MR after the shared monitor confirms that the current branch has none.

The shared monitor is the only owner of PR/MR status queries. The environment panel loads branch and diff information separately and does not start a second status lookup. Tasks from the same repository are grouped into one batch query, and rebuilding the runtime task list with equivalent task objects does not immediately repeat that query. Status still updates on the monitor interval, manual refreshes, and explicit refreshes after commits or pushes. Structured states such as a missing CLI, missing authentication, or lookup failure flow through the same snapshot to every surface.

The lookup runs in the task's actual workspace on its execution device: GitHub uses gh, and GitLab uses glab. In a single-machine Wework setup, the local executor runs the command directly, so a separate cloud Git service connection is not required. Install and authenticate the corresponding CLI on that machine:

gh auth login
glab auth login

Open Settings → Git hosting to inspect whether local gh and glab are installed and authenticated, open their installation guides, or copy the login commands. The page also provides a Show PR / MR status switch. Turning it off stops status lookup commands while keeping the create PR/MR action available. Wework reads CLI status only and does not store access tokens.

When glab has multiple GitLab instances configured, the settings page reports the GitLab CLI as Ready if at least one instance authenticates successfully; an expired or unauthenticated instance does not hide another usable instance. MR lookup for a specific repository still selects the GitLab instance from that workspace's Git remote, so the repository's own instance must also remain authenticated.

If the current branch has no PR or MR, the environment panel continues to show the create action. The create action also remains available when the CLI is missing, unauthenticated, or temporarily fails, together with a relevant recovery hint. Wework refreshes the environment after commit-and-push or push, and reopening the environment panel queries the latest status again.

Link a project space

After enabling Settings → General → Experimental features, open Edit project for a local project and configure Automatically join project space. A local project is the code and execution workspace, while a project space is the task-tracking and collaboration board. Linking them does not move or copy project files, and neither resource replaces the other.

Create a local or cloud project space

The Collaboration page always shows the current device's Local space in the sidebar. When it is empty, the guide offers Add folder. After you choose a directory and confirm the project name, Wework registers it as a Task project and adds it to the local space. Cloud projects are still created inside a cloud space, and the creation UI identifies the actual storage location:

• A local project is stored on the current device and is available only on that device.
• A cloud project is stored in Wegent Cloud and supports collaboration across devices signed in to the same account. Selecting it while signed out starts the sign-in flow. If the account has no cloud space after sign-in, Wework creates one before continuing project creation.

While creating a cloud space, the button shows Creating… and prevents duplicate submissions. If creation fails, the dialog displays the error and keeps your input so you can edit it and retry. A successful save opens the new space or continues the project creation you started earlier.

The storage location cannot be changed after the project is created. The task source (built-in tasks, GitHub, or GitLab) controls where task data is read from; it does not change whether the project is stored locally or in the cloud.

Create a cloud collaboration project from a template

Choose a template through Discover templates when creating a project. Bundled Agents use the current device and its default model. The device must be online and accessible to the signed-in account; importing into an existing project also requires a device grant for that project. Historical offline records for the same desktop neither block creation nor become execution targets.

If the current execution device is unavailable, check its cloud connection and use permissions. If multiple online records match the same desktop, resolve the execution-device ambiguity before continuing.

After selecting a template, creation waits for the execution-device list to finish loading. If loading fails, the execution environment section shows the error and a Retry action; creation becomes available after a successful refresh.

Configure local project collaborators

Wework automatically maintains a Current device agent in the local space, so users do not need to create an agent first. A new local project includes Me and the Current device agent by default. You can remove the agent before creation or add it again through Add collaborator. Creating a project does not automatically create a collaboration group.

When two or more agents are selected, the creation flow recommends organizing them into a collaboration group. After confirming, choose a generation model and optionally add collaboration instructions in the task composer. Wework progressively generates the leader, member responsibilities, assignment principles, and suggested workflow. You can edit the result before saving and update it later in project settings.

Use workspace agents in a project

After creating or adding an agent under the workspace's Settings → Collaboration participants → Agents, a project administrator can select it directly under Assignee → Workspace agents when creating or editing an Issue. Saving the assignment enables the agent in the project before assigning and executing the task. Administrators can also enable it beforehand through Project settings → Agents → Add agent → Existing agents, so members can assign it or call it through an @ mention. Catalogs show the display name entered during creation, or the resource name when no display name is set.

Local spaces save the agent configuration in the project, preserving its resource name, display name, model policy, and tools. In cloud spaces, workspace sharing grants use permission, while a project binding determines where the agent is available. Sharing does not grant permission to edit its source definition. Execution still requires an authorized project device and model.

Add and create Agents

When adding an Agent, search existing Agents by name or owning space, or open the creation form. New Agents default to Automatic selection for execution and the first available cloud model. The basic tab shows the current environment and model in its footer, so you can create the Agent without opening runtime settings.

Open Runtime settings to change these defaults. The environment menu lists automatic selection, selection at run time, and specific devices, with project shared devices before personal devices. Search by name or device ID. Only online devices appear initially; use Show offline devices in the bottom-right corner to include other devices. Native models are added only after selecting a specific device. Editing an existing Agent preserves its saved choices.

Cloud model requests end after 10 seconds and release the pending cache entry, so refreshing starts a new request. You can still select and save a cloud model while device-native model discovery fails or remains pending. Collaboration groups load their member list independently. A member loading failure offers a retry; loaded groups, Agents, and group saves remain available.

Basic project settings initially show project properties. Expand Tags to load task tags, with retry on failure. Once loaded, tags used by tasks remain manageable; renaming or deleting a tag also updates the affected tasks.

Set cloud board access

Cloud projects have two access modes: Private and Public. A public project grants every signed-in user the Viewer (read-only) or Developer (create and edit issues) role. A private project is available only through existing grants. Project roles are Owner, Maintainer, Developer, and Viewer. Owners manage the project and members; Maintainers can also manage issue security. Developers and above can assign the issue owner, and the issue creator can always assign their own issue.

Issue visibility is set separately during project creation, in project settings, and on each issue. Choose whether new issues default to Visible to project members or Related people only when creating the project; Maintainers can change the default or individual issues later. Owners and Maintainers see every issue. Other users see open issues and issues related to them: issues they created, are assigned to, collaborate on, have an active execution task for, or that are assigned to a robot they created. Unrelated issues are omitted from boards, tables, execution lists, and project conversations. Opening one directly returns not found.

DingTalk controls access to AI Table records. Wework project roles control entry and editing in its table view.

Import more projects into the local space

Wework automatically adds local Task projects to the local space during initial setup. To add more projects later, open the local space's … menu or the project page's Add project menu:

• Import existing project lists projects that already exist on the Tasks page but are not yet in the local space. Wework deduplicates them by runtime project identity and normalized workspace roots, so projects already shown in the local space are excluded.
• Add folder selects a new local directory, registers its Task project, and adds it to the local space immediately.

Background synchronization does not automatically restore an archived local collaboration project, preventing a project the user removed from reappearing. Explicitly choosing its Task project from Import existing project restores the corresponding local collaboration project. The sidebar refreshes after the import, and restarting Wework does not create a duplicate.

New conversations started in that local project inherit the selected project space. Before the first message is sent, the composer shows Add to board · Project space name. Sending creates a task in the selected local or cloud project space and links the conversation. Repeated synchronization of the same conversation does not create duplicate board tasks.

The default project space belongs to the local project's settings and is stored with that project's device-local state; the project space does not keep a reverse link. Use the composer's + menu to select, replace, or remove the project space for an individual conversation before sending.

Project-space lists, default-space selection, and current-task links are resolved in the background. The composer, image and file paste, attachment upload, and message sending remain available while a lookup or link is pending. Wework adds the project context or completes the task link after the result arrives instead of blocking the conversation with a linking state.

Initialize the project execution environment

Creating and manually handling an issue does not require an initialized execution environment. Starting an AI execution task requires the project's execution environment to be initialized on at least one online device. If the collaboration home reports that the environment is not initialized, choose Configure execution environment, initialize an available device in project settings, and then return to the issue to continue execution.

After initialization, the collaboration home reads the latest project configuration and device status again; reloading the page or reopening the project is not required. If the device is marked complete but the warning remains, confirm that the device is still online and reopen the execution-environment settings to check the initialization result.

Board quick start

You can create an issue even when no device has been added, the device is offline, or the environment is not initialized. Creating an issue does not redirect to execution environment settings. Manual work can continue; configure the environment when AI execution is needed.

The first time an empty project-space board is opened, Wework shows a collapsible three-step guide above the existing board:

1. Create the first issue. Choose the Build feature, Fix problem, or Research proposal template to start with a useful description structure.
2. Open the card details to review its description, owner, execution progress, and deliverables.
3. Drag the card from Inbox to Ready and confirm that the board action updates its status.

Each completed step is marked automatically, and the guide hides after all three steps are complete. Choose Collapse to reduce its footprint temporarily, or Don't show again to disable it for the current user and project space. Boards that already contain items do not interrupt users with this first-run guide.

Empty columns also explain what belongs in each stage and name the creation action that is currently available. During a drag, the destination column describes the resulting status. The default My tasks board uses task terminology, while other project spaces continue to use issue terminology.

Save and switch board views

The native task board's view dropdown on the right provides switching, creation, and board settings on the same toolbar as Focus view and Archived. The base board groups Issues by the five default statuses: Inbox, Pending, In progress, In review, and Completed. Status and custom tags remain separate Issue properties.

Project administrators can save multiple views, bind each lane to a status or tag, reorder lanes, configure tag filters, and choose the project default view. Entering a project opens its default; subsequent switches apply to the current visit. Views and their default are shared with project members. Deleting the default view restores the base board. Lane settings and card fields are edited in one dialog and saved together; card fields apply to every view in the project.

Add an Other (unmatched) lane, name it Backlog, and move it to the left. Each view supports one such lane. It displays Issues within the view filters that match none of the other status or tag lanes. New unmatched Issues appear automatically, including those with unrelated business tags. Dragging back removes all stage tags bound by this view while preserving other tags and status. If the status still matches another status lane, change the status first. A return that would violate the view filters is also blocked. The lane’s create action keeps the normal initial status and supplies tags satisfying the view filters. The action is hidden when that status matches another lane or the filters cannot be satisfied.

Tag names allow up to 32 Unicode code points, including supplementary characters such as emoji. Stored names have no leading or trailing whitespace; lanes and filters must reference the same canonical names. Issue tags, project tags, tag lanes, and filters use the same length limit. Longer input displays an error and cannot be saved; names are never automatically truncated. Historical long tags retain their original values when read or when unrelated fields such as titles change.

Each Issue and the tag catalog saved in project settings allow up to 20 distinct tags. Dragging an Issue with 19 tags into a new tag lane adds its twentieth tag. Adding another tag at the limit displays an error, preserves the original tags and version, and shows no success feedback. Replacing a tag between two tag lanes remains available. Tag lists are never automatically truncated; historical lists above the limit remain intact when read or when unrelated fields change.

Renaming or deleting a tag in a native project saves the catalog, tags on undeleted Issues, lane bindings, and filter references together. A project version conflict or any Issue update failure rolls back the entire operation so it can be retried after resolving the error. Externally hosted Issues do not support this transaction across records. Failed bulk status changes in the table list the affected Issues and reasons; successful Issues are deselected while failed Issues stay selected for retry.

Drag direction	Issue changes
Status → Status	Update status and keep tags
Status → Tag	Add the destination tag and keep status
Tag → Status	Update status and keep tags
Tag → Tag	Remove the source tag, add the destination tag, and keep other tags and status

An Issue can appear in both its matching status and tag lanes. After a cross-type drag, the destination card is highlighted and feedback describes the actual change. Dragging into a tag lane never reopens a completed Issue. Custom views with In progress or In review lanes also support Focus view to expand execution progress.

Existing projects keep the base board without converting historical Issue statuses or tags. Concurrent configuration changes produce a conflict message and refresh the latest configuration. Older clients cannot edit unknown view formats created by newer versions.

Quick tag filters

Choose All tags in the board toolbar, type to find tags, and select one or more. An Issue matches if it contains any selected tag. The filter preserves lane grouping and combines with board search and saved-view conditions. Clear the selection to show all tags; switching projects or views resets it. Filtering does not change shared views.

Edit Issue properties

Tags, status, priority, assignee, parent, date range, and milestone save immediately for existing Issues. Press Enter or leave the title field to save a title change. Type in the milestone picker to search; choose Not set to remove its association. New Issue properties are still submitted together when creating the Issue.

Only the description requires Save. Saving properties never submits an unsaved description, and cancelling description editing does not revert saved properties. Failures display an error and a retry action. Consecutive changes are saved in order; submitted changes continue to finish after leaving the detail view.

Sub-issue progress on cards

Issue cards with sub-issues show a progress ring and Sub-issues 2/5, meaning 2 of 5 direct sub-issues are completed. The ring turns green when all are complete. Select this control to enter the Issue's sub-issue board without opening its details.

Progress counts direct sub-issues that the current user can view and that are not archived. It excludes deeper descendants and is independent of search, tag filters, and grouping. The control is hidden when no eligible sub-issues exist. Local and cloud projects share this presentation.

Desktop regression: pnpm --filter wework e2e:desktop --segment collaboration-parent-board. The new progress checks share the existing parent-board CI checkpoint and desktop runtime.

Lane sorting

Each lane on a native project-space board has its own Sort by control and defaults to highest priority first. Add ascending or descending rules for priority, creation time, and update time, then move rules up or down or remove them. Rules apply from top to bottom: each subsequent rule breaks ties, and manual order breaks any remaining ties. Choose Manual order to reorder cards within status, priority, assignee, or tag lanes, or insert a card into another lane at a specific position. Non-status lanes can mix Issues with different statuses; reordering within a lane preserves status, assignee, and tags. Manual positions use the project’s shared order across groupings. Preferences are saved on the current device by user, project space, grouping, and lane, are restored when reopening the board, and do not affect other members. Drop onto the blank space at the end of a lane to append a card. Group fields and position are saved together; a failed save commits neither. Changes to different lane preferences in multiple windows are retained independently and synchronized to open boards.

Desktop sorting regression: pnpm --filter wework e2e:desktop --segment collaboration-board-sorting. This independent checkpoint runs in Core CI against the real cloud backend and local SQLite, covering default priority, independent compound lane rules, restoration after window reloads, rejected within-lane reordering under automatic sorting, and persistence of manual drags and cross-lane moves.

Post-save refresh recovery regression: pnpm --filter wework e2e:desktop --segment collaboration-board-move-recovery. This independent Core CI checkpoint uses a real Developer member with three visible Issues interleaved with hidden siblings. It verifies backward moves, visible order after interrupted snapshot delivery, recovery on reload, and fields and ordering across concurrent moves and out-of-order snapshots. The test faults only transport of real backend responses and verifies that hidden Issues remain invisible.

Calendar, Gantt, and table views

Use the project-space header to switch among Board, Calendar, Gantt, and Table. Issue details use one date-range control for the start and end dates. If only one date is set, Calendar and Gantt treat the issue as a one-day task.

• Calendar displays tasks by month, week, or day. Multi-day tasks use continuous bars; when a task crosses a week boundary, each row keeps its outer spacing and continues on the next row. Dragging any segment moves the whole task and highlights the destination dates. Calendar does not expose separate start or end resize handles.
• Gantt displays a week, month, quarter, or year timeline. Drag the whole bar to reschedule a task while preserving its duration. Hover the bar and drag either edge to change only the start or end date. Unscheduled tasks appear below the timeline and can be dragged onto a date.
• Table shows title, status, assignee, tags, start date, end date, execution state, and updated time by default. Issue IDs and assignment sources are hidden by default. Select a sortable header to toggle ascending and descending order; status, assignee, and tag headers provide filters. Selecting multiple rows enables bulk status changes and bulk archive, while a single-row archive uses an icon action.

Calendar and Gantt filters, grouping, and sorting are first stored as personal settings on the current device. Choose Restore project settings to discard personal changes. Members with project-management permission can choose Save as project settings so other members open the project with the same defaults.

Execution environment in Project settings

In a collaboration project, open Project settings → Execution environment to add a repository and initialize an execution environment when needed. A project without a repository can use a blank workspace. Normally, selecting a repository or entering its Git URL is enough: the name and directory are derived automatically. Expand Advanced options only to customize the name, directory, or branch. Setup steps are optional; no placeholder fields are required to save the configuration.

The Human processing settings page only explains the direct-assignment and review workflow; project administrators do not need to fill in another form. Actions happen in the Issue detail. See Work on an Issue assigned to me.

Message AI

Select the always-visible Chat button on the right of the board to expand its conversation sidebar. The New conversation icon next to a project in the collaboration sidebar also opens it. No collaboration group, AI leader, or experimental feature is required. Both local and cloud projects are supported. New conversations run on the current computer with the current project board as their default context, subject to the user's actual access and execution permissions.

Send a message directly without selecting another project or working directory. The sidebar header identifies the current project. Start new conversations, switch between existing conversations, or reopen the sidebar and choose a previous conversation to continue it. Local and cloud project histories are kept separate. If the local execution environment is unavailable, the sidebar reports the error; send again after recovery.

Opening a conversation does not enable background project coordination. For work that needs a tracked owner, status, and deliverables, create a board task and assign a member, robot, or collaboration group.

Issue details and execution tasks

Opening an issue from a project-space board shows its attachments directly in the detail panel, with actions to download, remove, or upload more files. The attachment section uses the same dividers and spacing as the other detail fields, and the complete row containing the file name and size downloads the file. A download shows progress; if it fails, the attachment remains available, an error is shown, and the row can be selected again to retry. The detail view keeps each file name and size visible instead of showing only an attachment count, so the context can be checked before execution starts.

Selecting New task in the issue detail opens the task conversation sidebar on the right. Describe the work in the composer and send it to create and link the execution task. Wework keeps this input step even when the issue is already Pending and never starts an empty task directly.

Comments in the issue activity have two different execution semantics:

• Sending a new top-level comment from the bottom composer creates a separate execution task from the issue title, description, attachments, and current project configuration. The new task can read the issue context, but it does not automatically inherit another execution task's conversation history.
• Selecting Reply inside an execution activity continues the original execution task and model session owned by that activity. Use it to add requirements, ask follow-up questions, or request corrections without creating another parallel task.

The Execution tasks section lists these independent tasks separately. An increased task count normally means that a new top-level comment was sent; a thread reply adds another turn to the original task instead.

For ordinary linked tasks, the Executor writes the issue's execution status from the runtime lifecycle. The board and the issue summary above the task composer do not write status independently. When the same task starts another turn or reaches a terminal state, they use the lifecycle transition as an invalidation signal and read the issue again, so an already-open board moves the issue between columns such as In progress and Pending review without a manual reload. For collaboration groups, the manager agent evaluates member outcomes and changes the issue status.

An issue that is no longer needed can be deleted from the board card menu, the table row actions, or the detail panel's "…" menu. Deletion is a soft delete: the issue and its sub-issues disappear from the board while their data is kept, and any run still executing is cancelled first so no orphaned process is left behind.

Project-space files

The Files tab in a project space shows shared files and delivery snapshots together. Shared files support upload, folder creation, rename or move, delete, and open; delivery files can be edited in the corresponding Issue’s delivery details. Select the preview action next to any shared file, delivery snapshot, or local task attachment to open it in the reusable workspace file preview panel on the right. The original download or open action remains available.

Local and remote project spaces share files differently. Local project spaces aggregate attachments sent by users and generated by AI during task conversations into the Task attachments area by default. Remote project spaces do not expose raw task attachments; files appear in the project-space Files tab only after a task is completed and explicitly delivered. Remote delivery does not include the entire conversation by default. Select the chat messages, conversation attachments, and local files or folders that should be included in the snapshot.

When another member assigns you a board task in a cloud project space, a Wework desktop app that is connected to that cloud and allowed to send system notifications displays a system notification. Reassigning the same owner or assigning a task to yourself does not send another notification.

Project space automation

Project space boards include an Automation tab that manages robot members and the execution queue together.

Robot members

Members with project permissions can add robots (AI members) and configure each robot's name, model, system prompt, visibility, execution environment (local or cloud), and execution mode. Tasks assigned to a robot are executed automatically by that robot.

Execution queue

The execution queue shows waiting and running tasks in columns:

• My tasks: tasks assigned to the current user that are not finished yet.
• One column per robot: tasks assigned to that robot.

The queue can be filtered by execution state (pending approval, queued, claimed, running, failed) and searched by title; running tasks show a spinning status icon. Robots configured for manual approval put their tasks into the pending approval state until a member approves them.

Automatic PR repair

Under PR automatic repair in the Automation tab, choose which abnormal states should continue the original task and ask AI to repair the change request. Supported triggers include failed checks, merge conflicts, Merge Queue failures, Merge Queue timeouts, and Merge Queue conflicts. An optional instruction can be appended for the AI. The configuration is stored with the project space and can be changed by members with project-management permission.

Automatic repair reuses the PR/MR monitoring state shown on the board and in the task sidebar. A trigger continues the linked task conversation rather than creating a replacement task, and a closed PR or MR does not trigger repair. The task's execution device must be online, and its gh or glab CLI must be able to read the repository.

Automation rules and AI management

Automation rules can run on a schedule or be triggered by project events such as task creation and by webhooks. Rules can be enabled or disabled, run immediately, inspected through their run history, and cancelled while unfinished. Scheduling runs on the server, so the Wework client does not need to remain online.

When a collaboration group handles an issue, its manager agent always reads the issue and eligible members before creating a workflow plan. The manager writes a specific execution prompt for each child task; members receive that assignment prompt rather than the static role description in group settings. After members report their outcomes, the manager decides whether to continue work, request review, or complete the issue. This flow does not depend on preset stages or a collaboration-mode option.

Issue activity describes assignments as “Project manager assigned ‘Task title’ to Member” without repeating a manager role label. When a linked execution is available, select View execution to open its details.

Each rule selects one assignment strategy:

• Manual selection fixes one project robot. When the rule fires, the original board task is assigned directly to that robot through the same execution flow used by an ordinary human assignment.
• AI managed lets an AI manager use a restricted MCP to read the original task and the capability descriptions of currently available project members and project robots, then directly assign the best candidate. If none is suitable, the task stays unassigned. The manager never executes or owns the original task; its final text is an audit record and is never parsed as an assignment.

AI management supports two manager sources. Custom AI selects a model and a local or cloud Wework device and uses the existing Wework runtime transport with exactly three MCP operations: read the task, list assignment candidates, and assign the task. Wegent agent uses an accessible, fully configured Wegent agent; the Backend creates a standard Task/Subtask and provides an equivalent MCP scoped to the current project, task, and automation run. If a project robot is selected, that robot is the business-task executor; if a project member is selected, automation only changes the assignee.

After a robot is selected, automation calls the same board-assignment path as a person. The robot keeps its current model, device, code workspace, and execution mode. Local work stays Queued while its device is unavailable and is claimed when Wework reconnects; the Backend dispatches cloud work. Execution records do not store model credentials; runtime configuration is resolved when execution starts.

The manager's decision is shown in its own parent comment. When the selected project robot starts, it creates a separate execution comment. Only the project robot's completion can move the original task to review; completing the manager decision does not complete the task.

The Automation tab is available for local, GitHub, and GitLab project spaces. DingTalk AI Table project spaces keep their data in the external table and do not show the tab.

Create a project from the composer

Open the project selector above a new-conversation composer to create a blank project or add an existing folder. After creation, the project appears in both the sidebar and the composer and immediately becomes the workspace for the current new conversation.

If you switch to a standalone conversation, use New conversation on the project row to create a fresh project conversation and select that project again. Wework does not reuse the standalone conversation's input or session state.

Regular workspaces and worktrees

• A regular workspace runs tasks directly in the project folder.
• A Git worktree gives each task an isolated branch and folder, which is useful for parallel changes.

For worktree tasks, the file tree, terminal, and development tools use the task's worktree. Commit or preserve changes before archiving the task.

Multiple devices

A project can reference a different folder on each local, cloud, or remote device. Select the device that contains the code when starting a task. Copying a task to another device requires a project folder on that device.

On macOS, open a folder from a terminal with wework . or wework /path/to/project.

Editing deliveries

Set a title and Markdown notes when delivering, and select the messages, files, or folders to include. The title initially uses the current task title.

After confirming a delivery from a task, a successful save closes the delivery dialog and opens the linked Issue's detail drawer so you can review its delivery records. If saving fails, the dialog stays open with an error so you can retry.

The delivery is saved in the project space that owns the linked Issue.

Open a delivery from its Issue and select Edit to change its title, notes, files, and selected messages. Select more source messages reads the source conversation under current access permissions. If the source is offline, deleted, or inaccessible, existing messages can still be kept or removed. Assets referenced by deliverable requirements cannot be removed directly.

Save changes updates the same delivery and preserves its link, source task, and initial delivery time. Editing does not complete tasks again or advance workflows. There is no version-history UI. Cancel makes no changes. Failed saves retain the form. On a concurrent-edit conflict, preserve any text you need before choosing Reload and discard edits to view the latest delivery.

Local projects support offline editing. Cloud projects require access to the Issue and a Developer or higher project role. The Files tab shows the saved attachments.

Desktop regression: pnpm --filter wework e2e:desktop --segment collaboration-delivery-editing. This independent Core CI checkpoint creates its own project and delivery and checks editing, cancellation, version conflicts, and persistence after reloading.

Copy an Issue web link

Open an Issue in a cloud project space and click Copy web link in its detail header to copy its address on the connected Wegent website. The button confirms success with Copied; if copying fails, click again to retry. Recipients still need to sign in and have access to the project.

Local project space Issues have no corresponding Wegent webpage, so this action is hidden. It is also hidden until the cloud website address is available.