Plan → share → build with your team

You’ve planned a project (if not, start with Plan & execute a project). Now you want a client or another team to watch it live and file issues — without handing them your repo, your internal docs, or edit access. That’s the collaboration tier: a hosted rendezvous server holds only a curated projection you push; your plan stays local and authoritative.

The loop: share a read-only live view → they file issues into a moderated inbox → you pull, triage into real tasks, and build → status flows back to them live.

We’ll use one running example: you’re sharing “Add rate limiting to our public API” with a client, Acme Corp.

1. Stand up a sync server — let your agent do it

The hosted tier runs anywhere — your own Cloudflare account, a Node box, or Docker. The fastest path hands the whole deploy to your coding agent:

plandesk deploy                      # list available guides
plandesk deploy cloudflare | claude  # agent runs the guide end-to-end

plandesk deploy prints the deploy guide to stdout; piping it to Claude Code (or | codex, | cursor-agent) lets the agent stand up the sync server on Cloudflare Workers + D1, deploy the portal to Pages, publish your project, and hand you back a share link — following a hosted, grounded runbook, writing nothing secret into your repo. See Collaboration & sync for the architecture.

Prefer to do it yourself? The same guide is human-readable — run plandesk deploy cloudflare and follow it, or self-host the @plandesk/sync-server package on any Node host.

Once a server exists, register your project against it (this writes the sync config and a git-ignored sync token — never committed):

plandesk publish --remote https://<your-sync-server>

2. Create a share for an audience

A share is one named audience with its own participant token. Mint one:

plandesk share create --audience "Acme Corp" --public --allow-submit

It prints a plandesk_share_… token once (only its hash is stored) and the link template. The shareable link is <your-portal-url>/p/<token>. Flags:

• --public — anyone with the link joins by name (Zoom-style). Omit it and use --invite a@b.com,c@d.com for an invite-only audience.
• --allow-submit — let this audience file issues. Omit for view-only.
• --expires 30d — time-box the link (h/d/w).

Then push the curated projection and keep it live:

plandesk push                 # upload the allow-list ClientView once
plandesk sync --watch         # …or stream every local change to the portal (~2s)

3. What your team sees

Send Acme the link. They open <portal>/p/<token>, enter their name, and get a scoped, read-only view of exactly what you shared:

• the board and flow canvas — tasks, statuses, dependency edges, shared docs;
• nothing internal — agent runs, internal documents, comments, and assignees are structurally absent from the projection, never just hidden;
• no edit handles — they can’t move a card, edit a task, or change status.

With --allow-submit, they get an Add issue affordance that files into a moderated inbox. They can watch their submissions, but they never touch your source of truth.

4. Pull their issues → triage → build

Submissions land on the hosted inbox. Bring them into a local triage inbox:

plandesk pull

Now triage from Claude Code over MCP — accepting a submission creates a real task through the normal write path, so your agent can pick it up:

Use Plan Desk MCP. Call list_submissions for this project. For each that’s a real bug, triage_submission to accept it — that creates a task on the plan. Then run the build loop: get_next_task, read the spec, make the change, run tests, update_task to done.

Accepting acks the status back to Acme, so their submission shows accepted. As your agent builds and flips tasks to done, sync --watch pushes each change — Acme watches in-progress → done on their board with no refresh. The issue they filed becomes a task you shipped, and they saw the whole thing.

Security by construction

Two invariants are enforced by the shape of the system, not careful filtering:

• Allow-list egress — the only bytes that leave your machine are the projected ClientView. A breach of the hosted server exposes only what you already shared.
• Proposals, never writes — a participant can only append a pending submission. Real work is created solely by your (or your agent’s) accept on the local source of truth.

A deployment is single-tenant today (one team / one self-hosted instance); org isolation is the gated next phase.

Recap

Step	You	Your team
Deploy	plandesk deploy cloudflare | claude	—
Share	plandesk share create --audience …	open the link, join by name
Live	plandesk sync --watch	watch status move, no refresh
Intake	plandesk pull	file issues into a moderated inbox
Build	list_submissions → triage_submission → build	see their issue go to done

Next steps

• Collaboration & sync — the architecture and security model
• From idea to development with Claude Code — the solo build loop
• CLI Reference — every collaboration command and flag