# Cohandry acceptance testing and advanced labs
## Build and deliver Task Garden with preview 0.1.4

Edition: October 30, 2026. Written for the Apple Silicon Mac desktop preview. This is the comprehensive manual acceptance guide, separate from the public learning walkthrough in TUTORIAL.html. Chapter numbers here match TEST-CHECKLIST.csv. Start with TUTORIAL.html when learning the app; use this guide to verify coverage and record results. It covers the current end-user feature set, with optional advanced labs for integrations that need additional accounts, machines or source installation. It does not claim those integrations have already passed live acceptance.

You will begin with a working little browser app, add a priority feature using agents, inspect evidence and commands, request a correction, and deliver an approved change through GitHub and CI. Then you will test reusable workflows, messages, questions, automation, checkpoints, backup and recovery.

**What is included:** `task-garden-starter/` contains the working app, eight baseline unit tests, a GitHub Actions workflow, and two reference documents. `TEST-CHECKLIST.csv` is your results sheet. The HTML edition of this guide can be opened in a browser and printed.

No GitHub repository or external account was created for you. No model calls, pushes, Slack messages or merges were performed to prepare this guide. You perform and authorize those steps during the exercises.

### Suggested sessions

| Session | Chapters | Goal |
| --- | --- | --- |
| First orientation | 1–5 | Understand fields, navigate, simulate a task |
| Real development | 6–10 | Connect a model and host, implement and review |
| GitHub delivery | 11–13 | Publish a PR, inspect CI, correct and merge |
| Broader acceptance | 14–20 | Templates, automation, lifecycle, recovery and backup |
| Optional integrations | 21–23 | Remote worker, MCP, Slack and portability |

**Recommended route for the full GitHub exercise:** chapters 1–6 → chapter 11 (repository preparation) → chapters 7–10 → chapter 12 → chapters 14–20. Chapter 13 is an alternative manual Git lab; chapters 21–22 are optional integrations. Preparing the repository before the file host avoids rebuilding your host configuration later.

Allow several sessions. Model response time, approvals and GitHub checks vary. Record **Pass**, **Fail**, **Blocked**, or **Not tested** rather than treating a skipped lab as a pass.

## 1. Prepare a disposable practice environment

1. Extract the tutorial ZIP. Copy `task-garden-starter` into a practice folder you own, such as `Documents/Cohandry Practice/task-garden`. Use a fresh copy for a repeat run. Do not use the Cohandry source repository or a real project.
2. Open Cohandry 0.1.4. Keep the extracted app bundle intact. The Mac preview is unsigned; do not disable macOS protections to open it. If your Mac blocks it, record installation as blocked and use an approved distribution path.
3. Find **Cohandry → Open application data folder**. Note its location privately. It contains the persistent coordinator state, distinct from your Task Garden folder. Do not move or copy a live database manually.
4. For Task Garden and Git exercises, install or use an existing Node 24+, Git and GitHub CLI (`gh`). Cohandry bundles its own launch runtime, but your Terminal and agent commands still need usable development tools. An editor is optional.
5. In Terminal, check `node --version`, `npm --version`, `git --version`, and `gh --version`. On this Mac, Node 24 is the reference runtime. If a command is missing, install it from its official vendor before continuing; do not let an agent install arbitrary software as a workaround.
6. Change directory into your copied Task Garden folder. You can type `cd `, drag the folder into Terminal, and press Return. Run:

```sh
npm test
npm run check
npm start
```

7. Open `http://127.0.0.1:4310`. Add “Review the guide”, complete it, filter Active/Completed, reload, delete it, and try Reset practice data. Stop the server with Ctrl-C after checking it.

**Expected:** eight unit tests pass, syntax checks pass, and baseline task actions work. There is no High priority feature yet. No `npm install` is needed: this starter has no external packages. Test coverage is task logic, not a complete automated browser suite.

**Record:** Cohandry version, macOS version, Node/Git/gh versions, initial test count and any launch issue. The guide assumes the current 0.1.4 labels; a few older details still say “brief” or “Knowledge”, meaning Project context or Resources.

## 2. Learn what belongs in each field

Use each field for one purpose. Examples in Cohandry are hints, not saved instructions. Replace them with your actual input.

| Field | Put this here | Do not repeat here |
| --- | --- | --- |
| Project name | Task Garden tutorial | The complete specification |
| Project context / brief | Durable purpose, audience, constraints and overall stopping boundary | Every task's detailed steps |
| Source document | Product specification or acceptance reference | Credentials or an implied grant of permission |
| Project note | A dated decision or concise shared fact | A second full copy of the project context |
| Agent responsibilities | Duties that remain true across many tasks | One task's temporary instructions |
| Role label | Optional short label such as Developer | A second responsibilities paragraph |
| Additional guidance | Optional special standing rules | The same project context again |
| Task name | Add high-priority tasks | The whole assignment |
| What should this agent do? | The exact work now, scope and stopping point | Background already inherited from the project |
| Success criteria | Observable results or evidence for approval | A rephrasing of all task steps |
| Team objective: Outcome and limits | A milestone the lead may break into assignments | An unrestricted instruction to finish everything |
| Workflow run input | This run's subject, input and limits | Fixed instructions already in the workflow template |
| Workstream scope | What this area may change and where it stops | Operating-system permissions |
| Connection/model | Actual account/provider and exact supported model ID | A role description such as “best coding model” |
| Absolute project folder | Existing folder on the execution computer | A GitHub URL or a relative path |
| Required capabilities | Capabilities actually provided by the host | Prompts that magically install tools |
| Shared resource lock | Same short identifier for agents sharing one mutable resource | A claim that files are protected from external editors |

Project context is snapshotted into new assignments. Editing it later does not rewrite old tasks. Imported sources are references; current decisions should identify the controlling source and revision. Agent settings also do not rewrite an already active attempt.

## 3. Create the paused project and import references

1. Choose **Projects → New project**.
2. Enter project name **Task Garden tutorial**.
3. Paste this into **Project context**:

> Task Garden is a small browser-local task list for one person learning Cohandry. Work only in the disposable Task Garden repository. Use vanilla HTML, CSS and JavaScript with Node's built-in tests; add no dependencies, login, telemetry, cloud database or deployment. Preserve task-title escaping and keyboard usability. The current milestone adds high-priority tasks as specified in the imported product brief and acceptance document. Produce measured file evidence and honest test results. Stop at reviewed delivery; publication and merging require my separate explicit action.

4. In **Resources**, choose the starter's `docs/PRODUCT-BRIEF.md` and `docs/ACCEPTANCE.md` (or import later under **Resources → Import documents**).
5. Select **Software delivery** as the starting team. Inspect the preview: Technical lead, Implementation agent, Code and test reviewer.
6. Keep the project connection **Demo**. Leave repository blank for now.
7. Review the summary and create the project.

**Expected:** the project exists and starts paused. No model task, GitHub publication or file editing starts just from setup. If setup partly fails, inspect the existing project before retrying; successful stages can remain saved.

Open each main area:

- **Work:** tasks, Questions, status filters, and **Filter this view** for agent/workstream.
- **Deliverables:** received copies of submitted files.
- **Team:** project agents and execution hosts.
- **Resources:** imported Sources and Project notes.
- **More:** Setup, Conversation, Activity history, Automation, Checkpoints and Project settings.
- **Project overview and activity:** expanded summary, messages and recent handoffs.

Go to **Resources → New note**. Set key `milestone-1-decision` and content:

> Milestone 1 uses a checkbox for High priority and a text badge on each high-priority task. The High priority filter includes both active and completed high-priority tasks. Existing stored tasks without the new property are normal priority. No sorting, due dates or deployment in this milestone.

Save, reopen, change “Milestone 1” to “Approved milestone 1”, save and verify the version increases. Read the source fingerprints/details. Importing the same filename again should ask you to edit/rename rather than silently overwrite it. PDF/Word extraction is not supported; use the supplied Markdown files.

## 4. Test a simulated direct task

1. Choose **New work → Direct task**.
2. Expand **Project context is included automatically**. You should see your context without another editable copy.
3. Enter:

| Field | Value |
| --- | --- |
| Task name | Demo acceptance checklist |
| Assigned agent | Implementation agent |
| What should this agent do? | Draft a five-item manual checklist for adding and completing tasks in Task Garden. This is a simulation; do not claim to inspect or modify files. |
| Success criteria | A short checklist covering add, complete, delete, filters and reload persistence, explicitly identified as simulated. |
| Approval | You only |
| File evidence | Text report allowed |

4. If the pack's implementation agent has required reviewers, its stronger policy still applies. For a clean owner-only simulation, create a separate **Demo guide** agent with responsibility “Produce clearly labeled simulated learning outputs”, coordinator text execution, Demo connection, no required reviewers and no file evidence. Assign this exercise to that agent instead. Do not weaken your real implementation agent just for the demo.
5. Queue it while paused. Verify it remains queued and the interface explains why.
6. Choose **Start new work**. Inspect the task as it proceeds to review. Read the output.
7. Approve the current revision using the displayed approval action. Verify the state changes and the Activity history records the decision.
8. Queue a second demo task, request changes with specific feedback, and inspect the rejected/change-requested state. Rejection alone is not a promise that a correction will appear: that needs a configured lead, rule or explicit correction assignment.
9. Pause new work again.

**Expected:** task states and human decisions work. Demo output is simulated and cannot prove source inspection, code edits, tests or tool execution. Do not use Demo to validate the actual development labs.

## 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.

## 6. Connect and verify a real model

Keep dispatch paused throughout configuration.

1. Open **Connections**. Choose either your supported ChatGPT account connection or a provider API connection.
2. For ChatGPT, complete the app's sign-in and use **Test connection**. Review the selected account/model. Sign-in and a successful inference test are different checks; record both.
3. For API execution, select the issuing provider (OpenAI, Anthropic, xAI or OpenRouter), enter its key only into the connection field, and Connect. Use an exact model ID supported by that provider. Keys are separate and API requests may be billed.
4. Open **Project settings → Connection & billing → Configure**. Select the intended route and model for this existing project. Changing global defaults only affects newly created projects.
5. Leave **Automatic paid fallback Disabled** for the core tutorial. This avoids turning a subscription quota event into an unexpected separately billed exercise.
6. In **Team → Configure**, inspect each real agent's Connection. Use **Inherit project default**, unless deliberately testing an override. Pack or existing agents may retain explicit Demo settings; correct those before real work.
7. Run a small text-only probe with your Demo guide agent temporarily switched to the real route: “Reply with one sentence stating you received this tutorial probe; do not claim file access.” Use text report evidence and no optional approval if permitted. Start dispatch and confirm an actual response, then pause. Return Demo guide to its explicit Demo connection afterward, so later simulation exercises stay simulated.

**Expected:** the task records the intended effective connection and succeeds. A configured key indicator alone does not prove model access. A tool-capable connection/model is needed for file and lead tool loops. Entered API keys are session-memory settings and may need reentering after restart; never put them in notes, sources or a repository.

Optional route tests: repeat the probe with a per-agent override, restore Inherit, and confirm other agents keep their routes. Multiple ChatGPT account profiles can be selected in account settings where available. Claude/Grok subscription sign-in is not a substitute for their supported API route. Do not deliberately exhaust a quota to test fallback. The fallback request cap is not a dollar budget.

## 7. Configure a local development host and roles

Before real code work, prepare GitHub using chapter 11 if you want **automatic Git delivery** from the first feature task. Otherwise use folder mode now and perform the manual Git path in chapter 13. Read both choices before creating the host: the current managed host form does not offer a general edit-every-setting screen.

In **Team → Add this computer**, enter:

| Field | Value |
| --- | --- |
| Host name | Task Garden Mac |
| Absolute project folder | Absolute path to your copied Task Garden folder (or clean clone from chapter 11) |
| Git workspace mode | Use the configured folder, OR allow isolated Git task workspaces and push submission branches if following chapter 11 |
| MCP tools | Leave empty; built-in file tools suffice |
| Project commands | Allow commands with approval for each execution |
| When the coordinator restarts | Keep this host stopped for this lab |
| Execution permission | Allow editing this folder and using the configured tools |

Read the permission description before saving. This grants real host-account execution, not an OS sandbox. The host should become Online. If offline, Start it and Refresh. The path is on the computer running the coordinator, not an arbitrary other machine.

Configure the three pack roles without replacing their useful existing settings:

**Implementation agent**

- Responsibilities: “Implement bounded Task Garden changes, add meaningful tests, run relevant checks with approval, and submit measured changed files plus a concise report.”
- Additional guidance: “Preserve existing behavior and title escaping. Do not install packages, deploy, edit credentials, merge, or publish a PR. Report failed checks and untested behavior honestly.”
- Execution host: Task Garden Mac. Clear irrelevant required capabilities; ensure selected ones are actually available.
- Require measured files. Default approval: **Required reviewer(s), then you**.

**Code and test reviewer**

- Responsibilities: “Inspect submitted source and test evidence against the product brief and acceptance criteria. Identify concrete defects; approve or request changes against the exact submission.”
- Coordinator execution, real inherited model, **Can coordinate work Yes**.
- **May review work from:** Implementation agent.
- **May assign work to:** Implementation agent, if you want bounded correction assignments.

**Technical lead**

- Responsibilities: “Break approved milestones into bounded assignments for the implementation agent, inspect progress and evidence, coordinate the authorized reviewer, and stop at owner decisions.”
- Coordinator execution, real inherited model, **Can coordinate work Yes**.
- **May assign work to:** Implementation agent (and reviewer if needed by the intended plan).
- Grant review targets only if you actually want the lead to act as a reviewer. Do not make every agent a competing reviewer.

Save the reviewer first, then reopen the implementation agent and select that reviewer under **Required reviewers of this agent's submissions**. This option only lists agents already authorized to review it. Keep Role label and Additional guidance optional; blank Role label uses the name.

Run **More → Setup** or **Project settings → Check setup**. Resolve blockers. A clean setup report is not a real model/tool health test. Start/Stop the idle host once and verify state. **Command permissions** changes require its running tasks to finish or be cancelled first.

## 8. Implement the priority feature with a direct task

If using automatic Git delivery, complete chapter 11 before queueing this task. Policy applies to new measured-file tasks, not retroactively to old ones.

Choose **New work → Direct task**, assigned to Implementation agent, workstream Implementation:

**Task name:** Add high-priority tasks

**What should this agent do?**

> Read docs/PRODUCT-BRIEF.md and docs/ACCEPTANCE.md, then implement milestone 1. Add a labeled High priority checkbox when adding a task, a visible text badge on high-priority tasks, and a High priority filter. Preserve add/complete/delete, current completion filters and reload persistence. Existing tasks without highPriority must be treated as normal. Add focused tests and update README. Use existing vanilla JavaScript and Node tools; install nothing. Request approval for npm test and npm run check, or their equivalent Node invocations. Publish measured evidence for every changed source, test and documentation file after the final changes and checks. Stop at submission. Do not publish a PR, merge or deploy.

**Success criteria:**

> All nine criteria in docs/ACCEPTANCE.md are met. Original tests remain passing; added tests verify priority and compatibility. Provide changed files, actual commands and results, and honest browser-test limitations. The priority badge uses text, controls are labeled, and task titles remain rendered as text. Submit measured files for review.

Set **Required reviewer(s), then you** and **Require measured files**. Queue while paused, inspect instructions, then Start new work.

### Approve commands and follow activity

Open **Inspect task**. Watch Activity, Console and Checks. For every requested command, inspect executable, arguments, working directory, purpose and timeout. Approve once only if it matches the exercise. `npm test` may be represented as Node plus the npm CLI script rather than a bare npm executable. Deny unrelated commands.

Approve the expected tests/checks promptly; approval expires after about five minutes and waiting consumes runtime. Watch streamed output and final exit status. Failed checks should return to the agent for correction, not be described as a pass. Later edits can make earlier checks stale. A successful exit is evidence for that command, not proof of every acceptance criterion.

**Expected:** real edits exist, relevant tests run, received files appear, and the source task awaits its configured review/owner gate. If only prose is returned, the wrong executor/connection or missing evidence configuration is a failure to investigate.

## 9. Inspect deliverables and request a real correction

1. In **Deliverables**, inspect each submitted copy. Open text previews, inspect size/SHA-256/revision and download a file. Compare at least one copy with the submission report. Images can be previewed when provided; binary metadata alone does not mean a reviewer saw its contents.
2. Inspect the automatic reviewer assignment. It should refer to the original task and current evidence. A completed reviewer task is not enough: look for an actual approval or request-changes decision on the source revision.
3. Use **Workspace actions → View changes**. This is a live local Git diff; it does not approve work. **Open task workspace** reveals the correct workspace; optional VS Code/Cursor buttons require those editors installed.
4. Run Task Garden from the actual task workspace (chapter 10) and perform every acceptance check. Create normal/high-priority tasks, complete a high-priority one, verify the priority filter includes it, reload, delete, and use the keyboard. Enter `<img src=x onerror=alert(1)>` as a title: it must display as text, without executing.
5. Test legacy data by adding a task with the starter before the feature, using the same browser origin and storage, then loading the modified app. That task should remain usable and normal priority. If you missed this preparation, use a separate fresh starter instance to seed that browser origin first. Do not overwrite real browsing data to manufacture the test.
6. Request one purposeful improvement, even if there is no defect: “Add a concise README section explaining how the High priority filter interacts with completed tasks. Keep behavior unchanged; rerun checks and resubmit measured evidence.” Record why the first submission was not accepted.
7. If a configured reviewer/lead creates a correction, follow that existing task. Otherwise explicitly ask the Technical lead for this bounded correction. Do not repeatedly create duplicate fixes. Automatic-Git corrections must start from the rejected submission's recorded commit; use the supported correction flow where available rather than a new unrelated branch from main.
8. Inspect the replacement submission, fresh evidence, reviewer decision and your final owner gate. Approve only the intended current revision. Keep the rejected history visible.

**Expected:** requested changes remain in history, corrected work has new evidence, and stale approval cannot silently apply to changed bytes. A final human approval may be unavailable until required reviewers approve. Reviewer-only tasks intentionally do not offer owner approval; cancellation is different from approval.

## 10. Use the interactive owner shell

Choose a non-running task associated with your trusted managed host. Pause new dispatch and let active editing finish before you touch the same files.

1. Open **Inspect task → Owner shell → Start shell**. Read the shown path and shell.
2. Run `pwd` and `git status --short --branch`. In automatic Git mode, the directory must be that task's existing worktree, not the main clone. A queued task whose worktree has not been created cannot open one yet.
3. Run `npm test` and `npm run check`. These are your own shell commands; they do not approve pending agent commands.
4. Run `npm start`, open `http://127.0.0.1:4310`, and do chapter 9's browser checks. If another practice server is already running, stop it first; otherwise you may inspect the wrong checkout. Stop the server with Ctrl-C.
5. Try arrow-key history, Tab completion and resizing the task panel. Switch Activity/Console/Checks and return: the brief tab switch should preserve the shell and unsent owner-message draft.
6. Choose Stop. Close/reopen the task and verify you do not have a persistent server running in that shell.

Shell start/exit makes prior task checks potentially stale. After owner edits, rerun checks and have the worker remeasure/resubmit evidence before approval. Do not edit an already approved Git submission and assume its approval now covers those changes.

The shell starts in the workspace but has your account's broader privileges. Terminal text is not sent to the model and is not kept as coordinator command logs. Record relevant results in your test sheet or an appropriate project note. The shell is local-only, not a remote terminal/takeover of agent stdin; closing the task or quitting ends it. It is not a persistent development-server manager.

## 11. Prepare the GitHub repository and automatic Git path

This is the recommended path for the main development test. Complete it before chapter 8. If already working in folder mode, use chapter 13 instead.

### 11.1 Create a private initialized repository

On the coordinator Mac, authenticate GitHub CLI to your intended account with `gh auth login`, then inspect `gh auth status`. The desktop app uses the coordinator's `gh` access; a GitHub connection in another app is separate. Do not paste authentication tokens into Cohandry notes.

In Terminal, inside your clean copied starter folder:

```sh
git init -b main
git add .
git commit -m "Start Task Garden tutorial"
gh repo create task-garden-cohandry-practice --private --source=. --remote=origin --push
```

The final command creates a real private repository and pushes the starter. Run it only when you intend that action. Pick a unique repository name if it already exists; do not reuse a real project accidentally. If Git asks for your author identity, configure the identity you want attached to this practice repository. If GitHub rejects pushing a workflow, resolve your normal GitHub authorization for workflow files rather than removing CI just to pass setup.

Open the repository on GitHub. Confirm visibility, `main`, starter files and the Actions run. The included workflow checks `npm test` and syntax on push-to-main, pull requests and manual dispatch, with a read-only token. No secrets/deployment setup are required. Check your account's Actions availability/usage before running many exercises. This tutorial provides CI, not public deployment.

### 11.2 Connect it to Cohandry

1. Pause the project. Open **Project settings → Repository → Connect GitHub / Repository actions**.
2. Choose **Connect existing repository**. Enter its HTTPS URL, such as `https://github.com/YOUR-ACCOUNT/task-garden-cohandry-practice`.
3. Connect and inspect the returned repository/base branch. Use **Check connection** for a fresh live access check. Saved metadata is not proof of live authentication.
4. Choose **Enable automatic Git workflow** and explicitly select the publication permission for this repository. This authorizes submission-branch pushes; PR publication and merging are still separate.
5. Create your chapter 7 host using the clean repository clone as its absolute folder and **Allow isolated Git task workspaces and push submission branches**. The worker computer needs its own functioning Git push authentication. On the local Mac that is usually the same OS account; still verify it rather than assuming.
6. The clone must match the connected remote. Keep it clean. Do not run another agent/editor that changes the same checkout during setup.

New measured-file tasks on this host fetch the configured base and use isolated task worktrees/branches. The worker commits submitted files and pushes its submission branch. Inspect the recorded base, branch, commit, digest and diff. Ordinary planning/reviewer tasks remain text work.

**Expected:** the chapter 8 feature task has a recorded Git submission. Approval is not integration, and a pushed branch is not a PR. Dirty/unsubmitted files, auth errors or conflicting base changes should stop for inspection, not trigger a force-push.

## 12. Publish, check, correct and merge the approved submission

### 12.1 Publish a draft PR

After exact-revision review and owner approval:

1. Open the task's **Review repository delivery**, or **Repository actions**.
2. Choose **Publish approved worker submission** and select the intended task. Authorize that operation for this repository/task.
3. Open the resulting **draft** PR. Verify head branch/commit, base `main`, files and description. Confirm it contains only the intended change.
4. The draft may need to be marked **Ready for review** in GitHub before merge. Cohandry does not automatically do that for you.
5. Choose **Check PR, reviews and CI** in Cohandry. Compare with GitHub's Checks/Files changed/Conversation pages. A successful Actions run should correspond to the submitted head, not an older commit.

Do not create a second PR if a response was lost; inspect GitHub first. Repository operations can have external effects even if a response fails.

### 12.2 Exercise PR feedback

Add a small actionable comment in your practice PR, for example: “Please clarify in README that tasks are stored only in this browser and are not synchronized.” Then refresh delivery in Cohandry.

Choose **Create correction from PR feedback**, inspect the feedback and authorize the bounded correction. The resulting assignment must pass the same measured-file and reviewer/owner gates. PR comments are input, not permissions. Inspect the corrected submission and its delivery. The old PR may remain for history; identify the replacement PR/head explicitly. Do not assume stacked PR rewriting or automatic closure.

Optional failure drill: use a separate small practice PR that deliberately changes one test expectation to fail, inspect the red check, and confirm the UI does not allow merge. Repair it through a reviewed correction, or close the drill PR in GitHub. Do not corrupt an approved feature submission solely to manufacture failure. You can also observe real failures if they occur naturally and record them.

### 12.3 Merge and verify integration

1. Check the current PR is ready, conflict-free, approved according to your repository policies, with at least one successful CI/check source and no pending/failing checks or outstanding review requests.
2. Choose **Merge approved pull request** only when you intend to change `main`. Review the selected task/revision/commit and explicitly authorize it. Cohandry requests an exact-head squash merge; GitHub policy may still block it.
3. Choose **Verify merged submission / release dependents** (or refresh the delivery until verification is recorded). Confirm the actual merge commit is present in the fetched base.
4. Inspect GitHub main and its post-merge CI. Fetch/pull the practice clone only when no task/editor is using it. Run tests from the integrated main and manually verify the app again.

Approval → PR publication → merge → verified integration are distinct steps. The active coordinator periodically monitors some published submissions, but does not automatically merge or invent a repair assignment. Paused projects are excluded from this monitor; use explicit refresh/verification while paused.

### 12.4 Test a dependent task

Ask the lead to create one documentation assignment depending on the feature task: “After the priority feature is integrated, add a short milestone summary to README. Do not modify runtime behavior. Stop at reviewed submission.” In automatic Git mode, it should remain blocked until the prerequisite's integrated commit is verified, even if the predecessor was approved. Confirm the dependency explanation and later release. If no structured child assignment was created, prose saying “I assigned it” is not a pass.

A replacement correction can release dependencies after verified integration without erasing the original rejection. Cross-repository promotion and stacked PR management are outside this exercise/support boundary.

## 13. Alternative: explicit manual Git operations

This path tests the separate manual repository controls. Do it on a separate small task/project so you do not mix manual delivery with automatic-managed submission state.

1. Disable automatic Git workflow only after outstanding automatic Git assignments are resolved; the app may correctly reject an unsafe policy change.
2. Connect the initialized repository. While paused, create a small file-evidence task, choose **Prepare task worktree**, and read the returned path.
3. Create a dedicated local host in ordinary folder mode pointed at that returned task worktree. Assign the file task to it before dispatch. Do not guess the worktree path or silently reuse the main clone.
4. Have the worker make one small README change and submit measured evidence.
5. Choose **Commit task evidence**, selecting that exact task. Inspect the resulting commit. Use **Inspect branch and CI**.
6. Use **Publish draft pull request** for the manual task and explicitly authorize publication. Inspect it on GitHub and complete review/merge through the supported exact-submission controls if available for that delivery, or through GitHub itself.
7. Use **Verify merged submission / release dependents** only where the task has supported recorded integration metadata; inspect the result rather than assuming a manually merged branch is registered automatically.

**Initialize an empty test repository** is a separate bootstrap operation. To test it, create an additional empty private practice repository on GitHub, then choose that action in Cohandry, read the operation help and explicitly authorize the initial commit/push. The main wizard expects an already initialized repository. This optional bootstrap lab is not required if chapter 11 already initialized yours.

## 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.

## 18. Pause, cancel, archive and recover

### Routine controls

- **Pause new work:** prevents new dispatch; an already running task/tool can finish. Test with a queued Demo guide task.
- **Cancel task:** use on a deliberately disposable queued task and verify it does not later run. For a running command, Cancel command targets that execution; inspect its recorded exit/cancellation rather than assuming external effects were undone.
- **Archive agent:** wait for its work to finish, archive the extra Demo guide, verify new work cannot dispatch to it, then Restore. Keep pack roles intact.
- **Archive project:** only with no running work. Use Project settings, archive and restore it. Restored projects should remain paused and history should remain available.

### Controlled recovery lab

Prefer observing a naturally failed small probe. For a deliberate safe error, add a temporary agent override with a clearly invalid model ID, queue a text-only harmless probe, and let it fail. Restore the correct model before retrying. Do not interrupt real file writes just to create a recovery screen.

Open **Recover interrupted run**. Read recorded actions, submitted artifacts, unfinished calls and child assignments. For this text-only probe note what the records actually establish. Enter a recovery note, confirm the inspection, and **Reconcile and queue retry / Queue retry** as offered. Paused dispatch should stay paused. Resume and verify one intended retry, with history retained.

For actual interrupted file/Git/application work, inspect the workspace, GitHub and active children first. Missing output does not prove an operation did not happen. Worker journals with unresolved intents may need host-side reconciliation; the UI retry is not a universal journal override. Do not delete journals or force-reset worktrees to get a green status. Record blocked recovery if safe continuation cannot be established.

Optional cancellation drill: on a dedicated task request a short harmless Node timer command, approve it, then Cancel command and inspect the result. Do not use an infinite process, install tools, or test cancellation against important work.

## 19. Backups, restore and exports

### 19.1 Coordinator backup

1. Pause dispatch, let work drain, and open **App settings → Coordinator backup → Create coordinator backup** (also linked from Project settings).
2. Record the returned backup/manifest paths privately. Keep the pair and any associated backup files together. Backup includes persistent projects and received artifacts; it does not replace a separate backup of working repositories/project folders, credentials or worker journals.
3. Verify the files exist using the application-data folder. Do not attach private backups to public bug reports.

### 19.2 Restore drill — advanced, source runtime required

There is no guided in-app restore wizard in this preview. Do not improvise copying an active SQLite file into the installed app. This lab requires the matching Cohandry source/runtime and its `scripts/backup.mjs`; otherwise mark Restore **Not tested**.

Quit coordinators/workers and preserve the current installation/data. From the matching source directory, with a supported Node runtime, run with your actual paths:

```sh
node scripts/backup.mjs restore /absolute/path/to/backup.sqlite.json /absolute/path/to/new-restored-data
```

The destination must not exist. The command checks manifest hash/integrity and refuses overwriting. Start a separate source runtime with `COHANDRY_DATA_DIR` set to the new destination, ensuring its ports are free. Do not point the packaged app at this directory without an intentional supported migration procedure.

Expected restored defaults: projects paused, previous workers revoked, running jobs moved to attention. Inspect records/artifacts, re-pair workers, reconnect credentials, and restore project assets/journals separately before any dispatch. Do not run the old and restored coordinator against the same workers simultaneously. A tampered or partial backup should be rejected; test tampering only on a copied backup in a disposable location.

### 19.3 Browser templates and legacy exports

In App settings, **Export JSON** and **View backup** contain browser templates, earlier runs and saved defaults, not the persistent coordinator database or provider credentials. Save before testing **Import JSON / Paste backup**: import replaces that browser data. Use your own exported file and confirm the replace warning. Current project history should remain separate.

**Export Python workflow runner** exports a standalone team runner, not a coordinator backup. It requires Python 3.10+ and an OpenRouter API key with separate billing; it does not export your ChatGPT account. Export and inspect the file, optionally syntax-check it, and only run live if you intentionally authorize API usage. Direct-provider exports are blocked rather than silently rerouted. Record Not tested if you have no supported route.

## 20. Restart and update acceptance

Pause, drain work, stop the development server and quit Cohandry. Reopen it and verify saved projects, tasks, notes, sources and deliverables. The host was configured not to auto-start; Start it explicitly. Reenter any session-only API key, run a small model probe, and inspect unresolved work before resuming.

A desktop update replaces the app bundle after quitting; its separate data directory remains. There is no automatic updater or downgrade-safe migration guarantee. Do not run two coordinators over one data directory. Remote workers do not update just because the coordinator does; update/restart them deliberately.

## 21. Optional remote worker and MCP lab

### Remote execution computer

Prerequisites: a second supported computer, matching worker source/runtime, the same practice repository cloned there, Git authentication for Git delivery, and a protected private connection to the coordinator. This Mac tutorial does not certify native Windows behavior.

1. In Team choose **Pair another computer**. Use a clear name and only real capabilities. Pairing registers credentials; it does not install software or start a process.
2. On that computer configure the matching worker with the coordinator gateway URL, scoped pairing token, its own data directory and owner-controlled agent configuration. Follow the matching source's COORDINATOR-GUIDE; do not guess tokens/paths. Keep credentials out of Git.
3. For a model-driven file worker, create a private configuration file **on the worker computer**, outside the repository, using its actual local absolute path. Start with:

```json
{
  "trustedHostExecution": true,
  "workspaceRoot": "/absolute/path/on/worker/task-garden",
  "commands": true,
  "gitWorkflow": false,
  "gitAllowPush": false,
  "servers": []
}
```

For Windows use JSON-escaped backslashes or forward slashes in the actual Windows path. Keep Git flags false for a simple remote file probe; set both true only for an intentionally enabled automatic Git workflow. Supply the following environment variables to the worker process through your private local configuration: `COHANDRY_COORDINATOR_URL` (the protected worker gateway URL), `COHANDRY_WORKER_TOKEN` (the exact pairing token), `COHANDRY_AGENT_CONFIG` (absolute path to this JSON), and `COHANDRY_DATA_DIR` (a separate existing/private worker data location). Never commit these credentials or use the owner token as the worker token. From matching worker source, run `node scripts/worker.mjs`. The built-in model-driven worker uses the coordinator's model broker rather than requiring model keys in this JSON.

For file tools, set a trusted local `workspaceRoot`. Commands require both the `commands` capability and `commands: true` in trusted `agentConfig`. For automatic Git set `gitWorkflow: true` and `gitAllowPush: true` and verify push access on that computer.
4. Start the worker using its pairing instructions; confirm Online and last contact. Assign a temporary agent to it and run a tiny measured-file documentation task.
5. Stop the idle remote process: new tasks should wait. Restart and verify normal claim. Revoke the unused pairing after the lab and verify it can no longer claim work.

Use HTTPS or an authenticated private-network transport. The desktop's protected local UI is not an ordinary remotely openable dashboard. Do not expose its localhost ports publicly. If remote transport is not provisioned, record **Blocked — private transport required**. Local owner shell is unavailable for remote/manual hosts; open the workspace on that host instead.

### MCP and fixed tool adapters

Task Garden needs no MCP. To test MCP, use a separate trusted throwaway project and an installed, documented stdio MCP server. Enter its absolute executable, one argument per line and exact allowed tool names in host setup. No particular server comes bundled by this tutorial. Inspect its tool catalog and permissions before granting access. Run a read-only query first and verify real evidence before allowing a controlled write.

MCP programs run with host privileges; the workspace folder does not sandbox arbitrary tools. Fixed Unity/Blender sessions cannot be silently redirected by automatic Git worktrees; that combination is rejected. Use a separately configured application project and explicit binding. A custom fixed adapter owns its own model/tool loop; pairing alone is not proof of integration. Mark unsupported/unavailable integrations Not tested rather than fabricating a result.

## 22. Optional Slack notification and approval lab

Prerequisites: a Slack workspace where you can install an app, a dedicated practice channel, explicit intended approvers, and a privately reachable dashboard URL if another device will open links.

1. Create a Slack app with the supplied `slack-manifest.json` (copied from this build's integration manifest). Enable Socket Mode, create an app token with `connections:write`, install the app to obtain its bot token, and invite it to the practice channel.
2. Copy the Slack member IDs of allowed approvers. Choose **Project settings → Slack → Configure Slack**.
3. Enter workspace URL, channel, allowed member IDs and reachable private dashboard URL. Enter tokens only into the app's credential fields. Save disabled first and inspect status.
4. When you intend outgoing notifications, enable them. Create a synthetic task requiring human approval. Confirm its task name/state/link reach the intended channel.
5. Approve the exact current revision as an allowed member. Test request changes on another synthetic task. With a consenting test participant, verify an unlisted member cannot approve. An old revision/action must not approve a later submission.
6. Inspect delivery failures/restart behavior. An uncertain send may already have reached Slack; inspect before retrying.
7. Disable/disconnect when finished; revoke the Slack app separately if you want its workspace access removed.

Notifications include names, state and links, not automatic upload of briefs/source/artifacts. Live Slack delivery was not performed while preparing the guide. The native desktop local service is protected and its localhost URL is not a shareable remote dashboard; a source deployment/private gateway may be needed for another device's links. Record that limitation instead of making the desktop port public.

## 23. Finish and evaluate

For each checklist row record result, task/PR identifier, screenshot or log reference, observed behavior, and any blocker. Test the app's clarity too:

- Could you explain each input before typing? Which fields still felt redundant?
- Did you know the next action and why a task was waiting?
- Could you distinguish a model statement, a command result, received files, reviewer approval, your approval and verified Git integration?
- Were controls readable with keyboard navigation and at a smaller window size? Did focus remain visible and dialogs scroll to their actions?
- Did pause, cancellation and recovery describe their real limits clearly?

Take screenshots of failures without keys/tokens/private information. Include app version, exact steps, expected versus actual result, task status/revision and whether Demo or real execution was used. Avoid sharing full backups or operation journals casually.

When finished, pause the tutorial project, stop hosts/shells/Task Garden servers, disable the practice automation and Slack route, archive the project if desired, and retain useful evidence. Keep the private GitHub practice repository for repeat testing or remove it yourself only when you no longer need its history.

### Quick troubleshooting

| Symptom | First checks |
| --- | --- |
| Nothing runs | Project paused? Host online? Agent enabled? Dependency/approval gate? Required capability mismatch? |
| Only simulated output | Project or agent still Demo? Wrong inherited/override route? |
| No file edits | Agent on coordinator text executor rather than file host? Correct folder? Real tool-capable model? |
| No command request | Commands enabled on both host and capability configuration? Task asking for a check? |
| Approval disabled | Required reviewer not finished? Wrong policy/revision? Evidence missing or stale? |
| Git connection fails | `gh auth status` on coordinator, initialized repo, correct access and HTTPS URL? |
| Worker cannot push | Git auth on execution host, matching remote, Git mode enabled, clean workspace? |
| Merge blocked | Draft, failed/pending/missing CI, review requests, conflict, changed head/base, GitHub policy? |
| Shell unavailable | Local trusted managed host? Existing task worktree? Correct scope? |
| Browser shows old app | Wrong server/worktree or port occupied? Stop old server, restart correct workspace and reload. |
| Messages wait | Paused project, active single-turn task, model reply blocked/failed? |
| Backup seems incomplete | Coordinator backup versus browser JSON versus working-repository backup are different. |

### Coverage and current boundaries

Core labs cover projects/packs, field help, sources/notes/versioning, workstreams/filters, model routes, project agents/permissions, managed hosts, commands/activity/checks, measured evidence, review/corrections, owner shell/editors, Git branches/PR/CI/integration, delegated objectives/dependencies, questions/conversation, templates, event rules, checkpoints, lifecycle/recovery, restart and backups/exports. Optional labs cover manual repository bootstrap/delivery, remote pairing/revocation, MCP/adapters, Slack, source restore, Python and legacy history. Not every error path can be forced safely through the UI; mark those observed-only or Not tested.

This preview is not an unattended production service, shared multi-user permission system, OS sandbox, guaranteed dollar budget, automatic conflict resolver, arbitrary app integration, scheduled calendar automation or public deployment system. Native Windows, real model/provider behavior, Slack and cross-machine recovery must be accepted in your environment rather than inferred from mocked regression tests.

### References

Menu/behavior checked against Cohandry 0.1.4 source, UX-FORMS, GIT-WORKFLOW, OWNER-SHELL, COMMAND-EXECUTION, CONNECTIONS and runtime/operations guides. Older repository prose sometimes predates implemented features; this tutorial uses the current source controls and calls out optional source-only procedures.

GitHub behavior references: [Creating a repository with GitHub CLI](https://cli.github.com/manual/gh_repo_create), [GitHub Actions workflow syntax](https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax), [setup-node documentation](https://github.com/actions/setup-node). The included CI uses the same pinned action revisions as this Cohandry preview; update pins through deliberate dependency review.

Optional Slack setup: [Socket Mode](https://docs.slack.dev/apis/events-api/using-socket-mode/). Exact vendor account screens may change; follow the current official controls, preserving the described scope.