Generalize #129 into project rooms for Workboard and external work items

What Problem This Solves

#129 describes GitHub PR workrooms as durable threads in project channels. The underlying product need is broader: a project channel should be able to organize durable, linkable threads for work items, including agent-owned Workboard tasks, without inventing a new channel or duplicating provider-specific room logic for every source.

A GitHub-only implementation would make Workboard and future providers build parallel thread lifecycles. This issue proposes a general project-room contract, using #129 as the first concrete GitHub example.

Why This Change Was Made

Generalize #129 around a stable work-item-to-thread relationship:

• An operator maps a project or repository to an existing ClickClack project channel.
• Each linked work item gets one durable root thread in that channel.
• The root is a bounded, editable summary; replies provide the workroom.
• Duplicate, concurrent, out-of-order, and restarted deliveries converge on the same root and semantic replies.
• Provider state remains authoritative in the provider; ClickClack owns the durable conversation and its visibility.

The first adapters would be:

1. GitHub PRs, following #129: GitHub owns PR state, reviews, checks, and merge decisions.
2. OpenClaw Workboard cards: Workboard owns agent assignment, execution lifecycle, sessions, proof, and artifacts; ClickClack provides the shared project-room conversation.

A Workboard card should explicitly create or link a ClickClack thread using stable references. Workboard already supports linked task, run, session, and source-URL references in its card contract: Workboard documentation, Workboard implementation.

User Impact

Operators can follow agent work and external work-item state in one project channel, while still opening the authoritative Workboard card or GitHub source. A single project channel can contain many durable workrooms without creating one channel per task or PR.

The boundaries remain explicit:

• GitHub is authoritative for repository state.
• Workboard is authoritative for local agent execution state.
• ClickClack is authoritative for the durable project-room conversation.
• Provider participants never determine ClickClack channel visibility or access.
• Workboard cards do not automatically create public threads without an explicit project/channel mapping.

Proposed Contract

An adapter supplies:

• a stable provider and work-item identity;
• a canonical source URL;
• a bounded summary and current-state fingerprint;
• an operator-configured destination project/channel;
• deterministic root and semantic-transition nonces;
• optional links between the provider item, Workboard card, and ClickClack thread.

Provider content is untrusted Markdown and must remain sanitized and length-bounded. Any missing or ambiguous destination authorization fails closed before a ClickClack write.

Acceptance Criteria

• One configured work item produces exactly one recoverable root thread.
• Duplicate, concurrent, out-of-order, and restarted deliveries do not create duplicate roots or semantic replies.
• A Workboard card can explicitly create, reopen, and reuse the same ClickClack thread.
• #129 remains a complete first adapter example for GitHub PR lifecycle reconciliation.
• No provider-derived channel creation, renaming, archiving, visibility changes, or GitHub writeback is required.
• The first implementation can remain adapter-side; a ClickClack core change is opened separately only when proof identifies a missing generic primitive.

Related Work

• Extends #129, the GitHub PR workroom example.
• #131 is useful prior design research but is not an implementation dependency; its broad channel lifecycle and authorization model should not be reused.
• Workboard is an OpenClaw-side source of agent-owned work, not a replacement for GitHub Issues, Linear, Jira, or ClickClack project-room history.

Open Questions

• Should the Workboard-to-ClickClack link be implemented entirely in a companion adapter, or should OpenClaw expose a small first-class integration hook?
• Should the first Workboard flow be explicit card action only, or also support an operator-configured dispatch rule?
• Should future providers reuse the same adapter-side work-item contract before any new ClickClack core primitive is added?

Evidence

• #129 defines the thread-first GitHub PR workroom direction and its security boundary.
• OpenClaw Workboard documents local agent-owned cards, linked references, sessions, execution metadata, proof, and artifacts.

Start with #129 to understand the GitHub PR workroom direction and compare it with the Workboard documentation and implementation linked in this issue. Review #131 only as prior design research; the work is complete when the adapter-side contract and open integration decisions are resolved against the stated acceptance criteria without requiring a ClickClack core change.