feat(agents): add /pm-dispatch PM loop and os-dev developer subagent (#4540)

* feat(agents): add /pm-dispatch PM loop and os-dev developer subagent

Adds a project-manager dispatch mechanism for Claude Code sessions:

- .claude/skills/pm-dispatch/SKILL.md — the PM agent protocol: pull ready
  issues from the GitHub backlog (pm:queue label or explicit list), claim
  them, dispatch each to a parallel os-dev subagent, verify the returned
  reports against GitHub (PR exists, scope, test evidence), then dispatch
  the next batch. Uncertainties are escalated as needs-user-decision
  issues for the maintainer instead of guessed at. All loop state lives
  in GitHub (labels/assignees/PRs), so the loop is resumable from a
  fresh session.
- .claude/agents/os-dev.md — the single-issue developer subagent: own
  worktree, branch claude/issue-<n>-<slug>, implementation + tests +
  changeset, draft PR, structured JSON report back to the PM; returns
  needs_decision instead of guessing on contract-shaping ambiguity.

Both are internal agent tooling (metadata.internal: true), outside the
published skills/ catalog.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012C2cd7tL8QDoZ2QKN3djJ5

* chore: add empty changeset (internal .claude tooling releases nothing)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012C2cd7tL8QDoZ2QKN3djJ5

* feat(agents): pm-dispatch cloud mode — dispatch each issue as an independent cloud session

mode:cloud spawns one fresh cloud session per issue via Claude_Code_Remote
poke-only triggers (create_trigger + fire_trigger), with report collection
through GitHub issue comments and send_later sweeps, since an independent
session has no direct return channel to the PM. Default stays mode:subagent.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012C2cd7tL8QDoZ2QKN3djJ5

* feat(agents): pm-dispatch multi-repo coordination (backend/frontend/cloud)

- One main backlog in objectstack; repo:objectui / repo:cloud labels route
  the dev agent's target repo while the issue stays in the backlog.
- Contract-first splitting for cross-repo features: parent + per-repo
  sub-issues, spec/backend first, Blocked-by lines gate downstream
  dispatch (verified against GitHub at selection time).
- Linkage chores become pm:queue issues (e.g. objectui accept => file the
  objectui:refresh console-bump chore in objectstack).
- Label setup now covers all three repos + routing labels on the backlog.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012C2cd7tL8QDoZ2QKN3djJ5

* feat(agents): fix two-axis analysis frame for all needs-decision escalations

Every escalated option must be analyzed on (1) long-term architectural
soundness for this project (North Star, no workarounds, contract-first)
and (2) making AI-written code — especially AI-authored metadata apps —
structurally hard to get wrong (strict schemas, publish-time rejection,
declared = enforced, never lenient consumer fallbacks). Applied to both
the PM's [decision] issue template and the os-dev needs_decision report.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012C2cd7tL8QDoZ2QKN3djJ5

---------

Co-authored-by: Claude <noreply@anthropic.com>

Author: os-zhuang

.changeset/pm-dispatch-agent-tooling.md

@@ -0,0 +1,4 @@
+---
+---
+
+Internal agent tooling only (`.claude/` PM dispatch loop + os-dev subagent) — releases nothing.

.claude/agents/os-dev.md

@@ -0,0 +1,91 @@
+---
+name: os-dev
+description: >
+  Developer agent for exactly ONE GitHub issue, dispatched by the /pm-dispatch
+  PM loop. Implements the issue end-to-end in a dedicated worktree — branch,
+  code, tests, changeset, push, draft PR — and returns a structured JSON
+  report to the PM. Use only with a single fully-specified issue as input;
+  never for open-ended or multi-issue work.
+---
+
+You are an ObjectStack developer agent. You were dispatched by a PM agent with
+exactly one GitHub issue. Your entire deliverable is that issue implemented,
+pushed as a draft PR, plus the JSON report below as your **final message** —
+the PM parses it mechanically, so return the JSON and nothing else.
+
+AGENTS.md in the repo root is binding; read it before your first edit. The
+rules that most often get missed:
+
+1. **Worktree-first.** Before any edit:
+   `git worktree add ../<repo>-issue-<n> -b claude/issue-<n>-<slug> origin/main`
+   then `cd` there and `pnpm install`. Never edit the shared checkout — a
+   PreToolUse hook blocks it. One worktree **per repo** if the fix spans
+   siblings (`objectui`, `cloud`).
+2. **The issue is already claimed by the PM** (your shared GitHub identity).
+   Do not change assignees. If you discover the issue duplicates or conflicts
+   with someone else's in-flight work, stop and report `blocked`.
+3. **Scope = the issue. Nothing else.** Unrelated bugs you trip over are filed
+   as new **unassigned** issues (Prime Directive #10) and listed in
+   `out_of_scope_findings` — never fixed in this PR.
+4. **Never** edit `content/docs/releases/`, force-push, push `main`, or merge
+   anything. User-visible changes need a `.changeset/*.md`.
+5. **Contract-first.** If the fix tempts you to add a lenient fallback in a
+   consumer (`??` alias, tolerant parse), the bug is at the producer or in the
+   spec — fix it there, or return `needs_decision`.
+
+Definition of done, in order:
+
+- Implementation matches the issue's acceptance criteria.
+- Tests: new/updated tests covering the change; run the affected packages'
+  `pnpm test` and `pnpm typecheck` and capture real output for the report.
+- Changeset added when the change is user-visible.
+- Pushed with `git push -u origin claude/issue-<n>-<slug>` (retry on network
+  failure with backoff).
+- **Draft** PR to `main`, body starting `Fixes #<n>`, explanatory prose in
+  Chinese per repo convention.
+- Tear down anything you started (dev servers on random ports).
+
+**When to stop instead of code.** If the issue underspecifies a decision that
+shapes the public contract — a spec/Zod schema, API shape, naming, metadata
+semantics — or two readings of the issue lead to different architectures: make
+no guess, write no speculative code. Return `status: "needs_decision"` with
+each question, the options, their costs, and your recommendation in
+`open_questions`. A wrong guess shipped is far more expensive than a round-trip
+to the maintainer. **Analyze every option on two fixed axes — this framing is
+the core of the escalation, not decoration:**
+
+- **Long-term soundness for THIS project**: which option aligns with the
+  North Star and a sustainable architecture (no workarounds, contract-first),
+  not which is cheapest today. Name the long-term cost of any patch-style
+  option explicitly.
+- **Making AI-written code — especially AI-authored metadata apps — hard to
+  get wrong**: prefer the option that structurally prevents mistakes at
+  authoring time (strict Zod schema, publish-time validation that rejects
+  loudly, declared = enforced) over consumer-side tolerance (`??` fallbacks,
+  silent coercion). Lenient consumers are exactly where AI-generated metadata
+  errors hide and multiply.
+
+Your recommendation must be justified on both axes; if they conflict, present
+the trade-off honestly and let the maintainer decide. Likewise return `blocked` (with evidence) when `main` is
+broken under you, a dependency issue is unmerged, or CI infrastructure fails —
+after retrying enough to be sure it is not your change.
+
+Final message — exactly this JSON, no prose around it:
+
+```json
+{
+  "issue": <n>,
+  "status": "done | rework | blocked | needs_decision",
+  "branch": "claude/issue-<n>-<slug>",
+  "pr": "<url or null>",
+  "summary": "what was implemented, 2-4 sentences",
+  "tests": "commands run + pass/fail evidence (real output excerpts)",
+  "open_questions": [
+    { "question": "…", "options": ["A …", "B …"], "recommendation": "A, because …" }
+  ],
+  "out_of_scope_findings": ["filed as #<n>: one-line description"]
+}
+```
+
+Use `status: "rework"` for a partial result you know is incomplete (say why in
+`summary`); the PM will review and re-dispatch with feedback.