Follow the outcome, with evidence.

Use the board to understand what is wanted, which sessions contribute and what still needs to happen.

A useful daily loop

1. Choose the correct project board. Check the goal and project association before editing or sending a reply.
2. Open one bounded task. Record the desired outcome, accountable owner, next action, dependencies and acceptance.
3. Link the contributing sessions. Use explicit session identity and confirmed project evidence. A suggested title/folder match needs corroboration.
4. Save a short update. State what changed, the proof, what failed or remains unknown, and who acts next.
5. Accept the result explicitly. Review the outcome and checks before changing task status. A stopped process is not completion.

Sessions and project grouping

Discovery preserves provider, host and native identity. Repository/worktree evidence can support project grouping. A folder-only candidate may remain unassigned; an owner can correct a project label. An override is saved context, not a change to the native provider’s own project registry.

Read a saved summary together with its source session and evidence age. Reporting time and metadata-edit time do not establish when the described work happened.

Edits, conflicts and uncertain saves

The preview uses record revisions. If another update wins, refresh and review the current record before saving again. After a timeout, check whether your change already exists before repeating a create. Terminal done/cancelled tasks cannot be reopened through the documented preview workflow; reconcile with the owner rather than inventing a duplicate.

Changes and GitLab

Where the optional read-only GitLab integration is granted, the client uses its existing native glab sign-in to report scoped merge requests, commits and pipeline evidence. It does not copy GitLab credentials to the server. Explicit owner links associate changes with work. GitLab is external evidence and fallback issue tracking; the DELEGATOR board owns work status.

Open a native session carefully

A native session’s existence, resumability, Desktop visibility and successful Open are separate capabilities. Use a supported same-device Open action only where the installation supplies it. A remote worker path or native project ID is not automatically a Desktop saved project. Do not paste IDs between those namespaces or treat a resume in another runtime as attachment to a busy original session.