Design: WorkBuddy as a first-class `init --agent` host

[cioerp]

Problem

AOCI-CODE currently recognises four hosts: Claude Code, Codex, Cursor and
OpenCode V1. WorkBuddy is not among them, so for that host:

• aoci init --agent workbuddy fails closed with hook.bad_agent;
• aoci doctor reports no WorkBuddy row at all, so an operator who did wire
  the server by hand cannot see that state from the tool;
• the managed AGENTS.md block is appended at the end of the file. WorkBuddy
  injects only the first few thousand characters of AGENTS.md into model
  context, so a trailing block is never read — the one written instruction
  that tells a model to load aoci_rules and aoci_overview before starting
  work is structurally unreachable on that host.

An operator can work around all three by hand, but the result is invisible to
doctor and unverified by any gate.

Why WorkBuddy is structurally different

WorkBuddy has no project-scoped MCP configuration surface. Its only entry is
the machine-level ~/.workbuddy/mcp.json, read and written by UserMcpProvider.
There is no project-level variant to write, and ./.mcp.json is only consulted
when a plugin declares it.

That collides with a fixed assumption in every existing installer: the server is
bound to one --repo, while this one file is shared by every project on the
machine. Copying the Claude implementation would make init for repository B
silently repoint repository A's server.

Proposed behaviour

1. Merge into the machine-level file, never overwrite a foreign entry.
   init --agent workbuddy writes mcpServers.aoci when that key is free or
   already bound to the current repository. When an aoci key points at a
   different repository, that entry is left byte-for-byte intact and the new one
   is written as aoci-<project>; if both keys are taken by other repositories,
   the command reports the conflict and changes nothing.
2. Write nothing into the repository. No Baseline path, no .gitignore
   line, no host file for git status to report. --hooks is inert, stated
   plainly rather than emulated.
3. Prepend the managed AGENTS.md block for this host only, because a
   trailing block is unreadable there. Every other host keeps the existing
   append behaviour; a file that already carries the block still gets an
   in-place replacement that never moves it.
4. Make it visible: doctor gains a WorkBuddy MCP (~/.workbuddy/mcp.json)
   row, the UI panel gains a matching integration key, and
   hooks.Detect probes the user-level file (a project-root probe would always
   miss).

Boundary

• The nine MCP tool names, their schemas and the binary name are unchanged.
• spec/public/ is not touched: it describes host capability contracts and does
  not enumerate hosts. The user-visible strings live in the Locale assets, and
  both locales gain the same keys.
• --agent all keeps its existing claude/codex/cursor set. It means "install
  project-level host configuration", and this host writes a file outside every
  repository; silently widening that set would change what all does.
• internal/machinecontract is untouched.

Evidence

• Control experiment on the changed packages: identical pass/fail sets before
  and after the change, compared by test name (comparing whole lines is
  useless because every line carries a duration).
• Ten new tests cover: idempotence, foreign-entry preservation, scoped-key
  conflict, broken-JSON refusal, existing-config preservation, the
  "another repository is not installed here" predicate, Detect, dispatch
  through Install, key sanitisation, and both block placements.
• End-to-end against a throwaway repository with an isolated HOME: the entry
  lands in the user file, the working tree stays clean, a second repository gets
  aoci-<project> without disturbing the first, doctor reports the row, and
  the managed block lands on line 1 with existing content intact and a second
  run changing nothing.

Open question for maintainers

The PR template asks whether a contribution that changes managed objects also
ships its cognition governance in the same commit. For this repository that
loop is driven through the MCP tools, which are bound to whichever repository
the host started them for — so a contributor working in two checkouts cannot
complete the loop for the second one without restarting the host. This
repository's own aoci check is not clean to begin with, so I would rather ask
than guess: should such a change ship with the governance entry, or is tracking
it as a follow-up acceptable?

[alkor2000]

设计可以。先说清一句：这是第一个让 init 往仓库外面写东西的宿主。你做了备份、合并、不动别人的条目、doctor 能看到，够了。八千字符截断我们验不了，按你实测记进文档。我去审 #99。