Projects

A project gives Wakers reusable access to code, documents, and other working files. Create a public project when several Wakers need the workspace; create a private project under one Waker when access should be limited to that Waker. A project configuration stores a workspace path and access relationship. It does not copy the original files, and deleting the configuration does not delete the directory on disk.

​

Choose public or private

Do not expose a broad parent directory that contains unrelated projects, personal files, or sensitive data.

​

Create a public project

Path: left navigation → Capabilities & Resources → Public Projects.

1. Select Create Public Project.
2. Choose a local directory or Git repository source supported by the page.
3. Enter a name that distinguishes the environment, repository, or purpose.
4. Verify the actual path, execution device, and access scope.
5. Save and reopen the item from the list.
6. In a new chat for a test Waker, select the project and perform a read-only check.

Completion check: the project appears in the public list, the intended Waker can select it, and it can read the expected files on the correct device.

​

Create a private project

Path: Waker Management → select a Waker → Capabilities & Resources → Projects.

1. Select Add project.
2. Choose a directory or repository that the Waker's execution environment can access.
3. Enter a clear name and save.
4. Start a new chat with the Waker, select the project, and run a read-only check.

A private project limits visibility but does not replace operating-system permissions. Keep readable and writable directories restricted under the Waker's Permissions page.

​

Use a project in a chat

1. Start a new task for the intended Waker or Group.
2. Select Project as the workspace type.
3. Choose the project and confirm the execution device and branch.
4. State the allowed read/write scope, artifact location, tests, and acceptance criteria.
5. After completion, inspect the actual files and version-control diff.

Start a new task when switching projects or primary branches so old workspace context is not reused.

​

Use a project in Autonomous Work

An automated trigger cannot correct a wrong directory interactively. Before rollout, verify:

• the path is stable and the device will be online at trigger time;
• another automation cannot overwrite the same branch or directory;
• write operations, tests, and output locations passed a manual run;
• connector and file permissions will remain valid during unattended execution.

After a project is moved, renamed, or re-permissioned, edit the Autonomous Work item and perform another manual run.

​

Use a project with Groups and WakerFlow

When several Wakers use the same project, define:

• the Waker responsible for actual modifications;
• the Wakers limited to analysis or review;
• whether each participant uses the same branch or an isolated workspace;
• the owner that consolidates and delivers the result.

Unisolated parallel writes can overwrite one another. Use independent branches, worktrees, or directories, then add a consolidation and human-confirmation step.

​

Update or delete a project configuration

After changing the path, device, or scope:

1. Pause automated tasks that depend on the project.
2. Update the project configuration.
3. Use a new chat for a read-only check, then validate one limited write.
4. Resume automation and Group use.

Before deletion, check chats, Autonomous Work, WakerFlows, and Groups. Removing the configuration neither cleans the original directory nor reverses file changes.

​

Troubleshooting