# Explore more Cohandry features

Continue here after TUTORIAL.html. These optional lessons cover everyday coordination beyond your first coding task. For systematic checks, recovery drills, backups and remote integrations, use ACCEPTANCE-TESTING.html. The original chapter numbers are retained for cross-reference.

## Prepare an optional Demo guide agent

For lessons that explicitly use simulation, create a Demo guide agent with responsibility “Produce clearly labeled simulated learning outputs”, coordinator text execution, Demo connection, no required reviewers and text-report evidence. Keep real coding agents on their real model connections. Simulation teaches controls without claiming file changes or real tool results.

## 5. Add workstreams and test navigation

Under **Work → Filter this view → New workstream**, create:

- **Implementation** — “Milestone 1 application and tests only. Stop before publication.”
- **Documentation** — “README and user instructions only. No runtime behavior changes.”

Filter by workstream, then by agent, and clear each filter. Empty filtered views are valid. Observe that Deliverables, Activity and Checkpoints also support relevant scope filters. A workstream separates histories/context; it is not a filesystem sandbox. Use a dedicated folder and host permissions for actual execution boundaries.


## 14. Give the team an objective

With the direct-task flow working, test delegated coordination. Use a tiny next milestone rather than asking the lead to build an entire app.

Choose **New work → Team objective**, select Technical lead, workstream Documentation:

**Title:** Document the approved Task Garden milestone

**Outcome and limits:**

> Read the current project references and integrated milestone. Assign the Implementation agent a documentation-only update explaining priority, filters, browser-local storage and test commands. Require measured README evidence and the configured code/test reviewer. Inspect results and request one scoped correction only if acceptance fails. Do not change application behavior, install packages, publish a PR, merge, deploy or begin another milestone. Stop after the reviewed submission and report the remaining owner decision.

**Success criteria:**

> Real child assignments are visible with recipients, dependencies and parent lineage. The README explains the four topics accurately. Review decisions refer to measured current evidence. The lead reports completion or a clear owner question and stops at the agreed boundary.

Start dispatch, follow child tasks and reviewer activity, and approve commands/decisions as needed. Compare the lead's prose to actual task records. It can only delegate/review the agents explicitly allowed in its configuration. Bounded invocation/chain limits can stop an overly large plan; split it instead of treating limits as an app crash.

### Questions and conversation

Run a separate small lead objective: “Before assigning any work, ask me whether a future labels feature should allow multiple labels or exactly one. Do not assume or edit files. Wait for my answer.” Open **Work → Questions**, answer “Multiple labels is the preference for a future milestone; no implementation is authorized now.” Verify it resumes within that boundary.

In **More → Conversation**, choose the lead and related assignment. Test **Ask for an update**, **Give feedback**, and **Update instructions within current scope** with short messages. Inspect Queued, Received by executor, Replied/failed statuses. Pause dispatch, send a harmless status request, confirm it waits, then resume. Receipt does not prove compliance; a single-turn request may finish before receiving a message. Read-only replies use saved project state, not guaranteed fresh filesystem inspection.


## 15. Reusable agent and team templates

Templates are browser-local reusable configuration, separate from persistent project agents. Editing a template does not automatically update an existing project agent. Export JSON for portability.

1. Open **Templates** and inspect Project packs, Agent templates and Team templates.
2. Create an agent template **Documentation helper**, responsibilities “Draft concise user documentation from the supplied approved context.” Optional role/guidance can be blank; choose Demo for the first practice copy.
3. In your project's **Team → Add from existing templates**, add it. Configure the project copy, then revisit the template to verify they are separate.
4. Create a team/workflow template **Documentation handoff**. Describe **When to use this workflow** as “Prepare a documentation outline and a review checklist for a bounded change.”
5. Add two tasks using valid agent templates. Use these fixed task values:

| Task | Assignment instructions | Success criteria |
| --- | --- | --- |
| Draft outline | Produce a short documentation outline for the change described in the run input. Use the inherited project constraints. Do not claim file inspection or modify files. | Four to six headings covering user behavior, limitations and verification, clearly labeled simulated in Demo. |
| Review outline | Review the earlier outline against the run input. Identify missing explanations and propose concrete wording; do not claim source or browser inspection. | A concise assessment with at least one specific improvement, distinguishing observed input from assumptions. |

Choose sequential execution and an approval gate for the first step.
6. Launch into the tutorial project with run input “Document High priority and browser-local persistence only; no code changes or publication.” Verify the selected project context is included along with this run input.
7. Observe the second task waits for its prerequisite/gate. Approve the first, then inspect the second. Pause the persistent project to test stopping new dispatch, then resume.
8. Duplicate/recreate a tiny independent parallel workflow for two unrelated text outputs. Confirm they are eligible independently; do not use parallel mode for two edits to the same folder. Use shared resource locks and isolated workspaces for mutable resources where appropriate.
9. Test editing/reordering/removing a draft template task, saving, and relaunching. Do not delete a template that is still referenced without reassigning it.

Local launches queue persistent coordinator tasks. **App settings → Advanced tools → Earlier browser runs** is retained legacy history, not the authoritative list of current persistent tasks. Legacy browser-run pause/stop controls apply only to an actual active legacy browser execution; do not mistake empty historical controls for current coordinator controls. Export a legacy result as Markdown if you have one; record Not tested when no such run exists.


## 16. Event automation

These are future-event rules, not calendar schedules. Use a one-shot scoped rule to avoid noisy loops.

1. Open **More → Automation → New automation**.
2. Name: **Decision note acknowledgement**.
3. When: **Project knowledge changes**. Record key: `tutorial-automation-probe`.
4. Assign to: Demo guide (Demo connection is sufficient here). Task name: **Acknowledge practice decision**.
5. Instructions: “Acknowledge the triggering practice note as simulated. Do not modify notes, create tasks or claim file inspection.”
6. Success criteria: “One short simulated acknowledgement, no external effects.” Approval: Required if you want a human gate.
7. Expand limits: maximum tasks created **1**, maximum chain depth **1**. Save. It becomes enabled for future events.
8. In Resources, create a note with exactly that key and content “This is a one-shot automation probe.” Resume dispatch if paused.
9. Confirm exactly one generated task, trigger context and firing count. Edit the note again; the lifetime limit should prevent another task. Enabling an exhausted rule does not reset its count.
10. Disable the rule. Inspect activity and limits.

Other supported events are Task awaits review, Task completes, Task approved, and Changes requested. Exercise one additional event on a dedicated Demo guide task if desired, always with a one-task lifetime limit and specific source agent. Avoid creating a second automatic review chain over the pack's existing reviewers.

If a real rule dispatch fails, inspect the error, repair its target/configuration, enable it if needed and use **Retry failed dispatches**. Successful dispatches should not duplicate. Do not manufacture failures by deleting active real agents.


## 17. Checkpoints and sessions

1. Finish a small real or demo task and open **More → Checkpoints**.
2. Filter by agent/workstream. Choose **Inspect checkpoint** and read summary, next steps, artifact references and technical details.
3. Confirm the checkpoint describes what actually happened. It is a durable summary, not hidden model reasoning or a complete replayable conversation.
4. With that agent idle and a checkpoint present, choose **Start new session**. Verify the generation increments and checkpoint remains.
5. Confirm this action did not itself queue or retry work. Queue a separate follow-up “Summarize the prior milestone from saved context, identifying any uncertainty.”
6. While an agent is running, session rotation should be unavailable. A missing checkpoint should also prevent rotation.

Record that context survives in summary form. Do not assume unlimited memory, provider-native compaction or a guarantee of exact model recall.