bugs.jsonl

{"_comment": "Bug intake file — append a line (JSON or plain text) and a monitor will auto-log it via `bl bug` and append a status update with the Bxxx id. Example: echo 'crash on malformed PoW header' >> bugs.jsonl"}
{"source": "dogfood/install", "date": "2026-06-29", "version": "0.8.7 (a36b48e5)", "severity": "high", "area": "cli/output", "title": "`c2c init --json` emits non-JSON: human log lines + two concatenated JSON objects on stdout", "detail": "Ran `c2c init --client claude --json`. stdout contained human lines like `[c2c register] no --alias given; auto-picked...` and `warning: relay identity init failed (rc=1)...` interleaved with TWO separate JSON objects. Not parseable as a single JSON document.", "expected": "With --json, stdout is exactly one valid JSON document; diagnostics/log lines go to stderr.", "repro": "c2c init --client claude --json"}
{"source": "dogfood/install", "date": "2026-06-29", "version": "0.8.7 (a36b48e5)", "severity": "medium", "area": "init/relay", "title": "Misleading 'relay identity init failed (rc=1)' warning when identity already exists", "detail": "init printed `relay identity init failed (rc=1). Relay features may not work.` Manual retry of `c2c relay identity init` revealed the real cause: `/home/xertrov/.config/c2c/identity.json already exists. Pass --force to overwrite.` Relay is actually fine; init treats 'already present' as failure.", "expected": "If relay identity already exists, init should report success/no-op, not a scary failure warning.", "repro": "c2c init on a host that already has ~/.config/c2c/identity.json"}
{"source": "dogfood/install", "date": "2026-06-29", "version": "0.8.7 (a36b48e5)", "severity": "medium", "area": "init/alias", "title": "init generates two different aliases for one session (MCP auto-register vs register step)", "detail": "After init, .mcp.json env has C2C_MCP_AUTO_REGISTER_ALIAS=claude-naava-aimu-q7j3, but init's register step picked claude-starling-tala-j5xb (what `whoami` reports). Once the MCP server loads it will auto-register the other alias, so live identity won't match what init reported.", "expected": "Single consistent alias across the MCP auto-register env and the register step.", "repro": "c2c init --client claude  (without --alias); compare .mcp.json env vs `c2c whoami`"}
{"source": "dogfood/install", "date": "2026-06-29", "version": "0.8.7 (a36b48e5)", "severity": "low", "area": "cli/git", "title": "Read-only commands spew `fatal: not a git repository` to stderr when run outside a repo", "detail": "`c2c whoami`, `c2c status`, `c2c doctor` all print `fatal: not a git repository (or any parent up to mount point /)` even though they don't need to be in a repo. whoami/status still work; output is just noisy.", "expected": "No git error output when the command doesn't require a repo.", "repro": "cd /tmp && c2c status"}
{"source": "dogfood/install", "date": "2026-06-29", "version": "0.8.7 (a36b48e5)", "severity": "low", "area": "cli/help-tiers", "title": "`doctor` listed under TIER 1 'SAFE (agents can use freely)' but hard-fails outside the c2c source repo", "detail": "`c2c --help` classifies `doctor` as Tier 1 safe, but running it errors: `must run from inside the c2c git repo.` It's effectively a dev-only command mis-tiered as agent-safe.", "expected": "Either make doctor work for end-user installs, or move it out of the Tier-1 'agents can use freely' list.", "repro": "cd /tmp && c2c doctor"}
{"source": "dogfood/install", "date": "2026-06-29", "version": "0.8.7 (a36b48e5)", "severity": "low", "area": "docs/packaging", "title": "c2c.im leads with `npm i -g` as primary method; fails on default `/usr` prefix and collides with standalone binary", "detail": "Docs primary method `npm i -g @clanker-code/c2c` failed two ways: (1) EACCES creating /usr/lib/node_modules (npm prefix=/usr, needs sudo/user-prefix); (2) after retry with --prefix ~/.local, EEXIST because a standalone `c2c` binary already lived at ~/.local/bin/c2c. npm package and standalone binary both claim that path.", "expected": "Docs note the prefix/sudo requirement; npm vs standalone-binary path collision is handled or documented.", "repro": "npm i -g @clanker-code/c2c  (with npm prefix=/usr and an existing ~/.local/bin/c2c)"}
[logged] B025 — c2c init --json emits non-JSON: human log lines + two concatenated JSON objects on stdout (severity: high, area: cli/output)
[logged] B020 — Misleading 'relay identity init failed (rc=1)' warning when identity already exists (severity: medium, area: init/relay)
[logged] B024 — init generates two different aliases for one session (MCP auto-register vs register step) (severity: medium, area: init/alias)
[logged] B022 — Read-only commands spew 'fatal: not a git repository' to stderr when run outside a repo (severity: low, area: cli/git)
[logged] B021 — 'doctor' listed under TIER 1 SAFE but hard-fails outside the c2c source repo (severity: low, area: cli/help-tiers)
[logged] B023 — c2c.im leads with npm i -g as primary method; fails on default /usr prefix and collides with standalone binary (severity: low, area: docs/packaging)
{"source": "dogfood/install", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "medium", "area": "install/distribution", "title": "npm-primary install lands in root-owned /usr on system-node hosts; every peer agent CLI installs user-local without root", "detail": "c2c.im leads with `npm i -g @clanker-code/c2c` as primary. On a host where node is distro-packaged (/usr/bin/node), npm's prefix is /usr, so `npm i -g` fails with EACCES (needs sudo). Evidence from this machine: ALL other agent CLIs install user-local without root -- codex & opencode via bun (~/.bun/install/global), pi via pnpm (~/.local/share/pnpm), kimi via uv (~/.local/share/uv/tools), claude via its own installer (~/.local/share/claude), plus bun/uv/rustup self-installers into ~/.local/bin or ~/.cargo. Only deno (pacman) is in /usr. c2c already supports user-local via `c2c install self` -> ~/.local/bin and prebuilt release binaries, but there is NO curl bootstrap (c2c.im/install.sh -> 404; no `curl|sh` documented), which is the canonical no-root pattern used by uv/rustup/bun/deno/starship/ollama.", "expected": "Default install is user-local and needs no root. Provide `curl -fsSL https://c2c.im/install.sh | sh` that drops the standalone binary into ~/.local/bin (warn if not on PATH). Demote `npm i -g` from primary, or note the /usr-prefix caveat.", "repro": "On a host with npm prefix=/usr: `npm i -g @clanker-code/c2c` -> EACCES mkdir /usr/lib/node_modules", "supersedes": "earlier low-sev docs/packaging note from 2026-06-29 (this is an install-UX bug, not just docs)"}
[logged] B026 — npm-primary install lands in root-owned /usr on system-node hosts (severity: medium, area: install/distribution) [supersedes B023]
{"source": "dogfood/install", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "medium", "type": "enhancement", "area": "install/website", "title": "Add install.sh curl-bootstrap to the website build; detect existing c2c and delegate to `c2c self-update`", "detail": "c2c.im/install.sh currently 404s. Ship a POSIX-sh bootstrap as part of the website build so `curl -fsSL https://c2c.im/install.sh | sh` does a no-root install (canonical pattern: uv/rustup/bun/deno/starship/ollama). It must be idempotent and double as the upgrade path: if a c2c is already on PATH, call `c2c self-update` instead of blindly reinstalling/overwriting.", "best_practices": ["No root, ever: install to ~/.local/bin (honor $XDG_BIN_HOME and a C2C_INSTALL_DIR override); refuse to write under /usr.", "Detect existing install: if `command -v c2c` resolves, run `c2c self-update` and exit; else fresh-install. Make re-running the script the supported upgrade route.", "Resolve OS/arch and pick the matching GitHub release asset; allow C2C_VERSION to pin a specific version (default latest).", "Integrity: download to a mktemp, verify sha256 (and ideally a signature -- minisign/cosign) BEFORE moving into place; atomic install via chmod +x then mv; trap-cleanup temp.", "Robust shell: set -eu, https-only, follow redirects, fail loudly if curl/tar missing; works non-interactively in CI (no prompts unless TTY); support --dry-run and a quiet mode.", "PATH hygiene: if install dir not on PATH, print the exact shell-rc line to add (don't edit rc files silently).", "Post-install: print next steps (`c2c init`, restart client / reload-plugins). Keep machine-readable output clean if a --json/-q mode is offered.", "Share asset-resolution + checksum logic with `c2c self-update` so bootstrap and in-place upgrade can't drift."], "expected": "`curl -fsSL https://c2c.im/install.sh | sh` installs or upgrades c2c user-local with no root and verifies integrity.", "related": ["B023", "install/distribution npm-prefix bug", "c2c self-update bug (below)"]}
{"source": "dogfood/install", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "medium", "type": "enhancement", "area": "cli/self-update", "title": "Add `c2c self-update` command (in-place upgrade of the running binary)", "detail": "No `self-update`/`update`/`upgrade` command exists today (all fall through to top-level usage; only `--version` and `restart-self` are present). install.sh needs this to delegate upgrades to. It should fetch the latest release, verify it, and atomically replace the running binary at its resolved path.", "best_practices": ["Naming: `c2c self-update` as canonical; accept `update`/`upgrade` as aliases.", "Update the binary AT ITS RESOLVED PATH (readlink -f argv0), not a hard-coded ~/.local/bin -- handle the file being read-only (current binary is r-xr-xr-x) by replacing the file, not writing in place.", "Atomic + 'text file busy'-safe: download to a temp file in the SAME directory, verify, chmod, then rename over the old path (rename, don't truncate-in-place).", "Integrity: verify sha256 + signature before swapping; never exec downloaded code other than the verified binary.", "Refuse-and-advise on system paths: if the binary lives under /usr (or another root-owned/pkg-managed path), don't silently sudo -- tell the user to use their package manager.", "Channels/pins: support stable vs prealpha/nightly and `--version X` to pin or downgrade; `--check` for a dry report (current vs latest, exit 0).", "Clear exit semantics: distinct 'already latest' vs 'updated to X' messages; nonzero only on real failure; offer `--json` with stdout kept clean (ref B025).", "Session safety: if updating the binary that is currently supervising a managed session, warn/defer and require an external restart (ref the Tier-3 restart-self caveat) rather than killing the live supervisor.", "Share asset-resolution + checksum code with install.sh."], "expected": "`c2c self-update` upgrades the running binary in place, verified and atomic, with a no-op-if-current path and a --check dry-run.", "related": ["install.sh website bug (above)", "B023", "B025"]}
[logged] B027 — Add install.sh curl-bootstrap to the website build; detect existing c2c and delegate to c2c self-update (severity: medium, area: install/website)
[logged] B028 — Add c2c self-update command (in-place upgrade of the running binary) (severity: medium, area: cli/self-update)
{"source": "dogfood/install", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "low", "area": "docs/help", "title": "Wrong GitHub issues URL in help/man output: points to anomalyco/c2c (should be clankercode/c2c)", "detail": "`c2c --help` EXIT CODES section says 'please report at https://github.com/anomalyco/c2c/issues'. The correct repo is github.com/clankercode/c2c. (npm scope @clanker-code/c2c is correct; anomalyco appears to be a stale/old org name leaking into user-facing output.)", "expected": "Help/man and any other user-facing references point to github.com/clankercode/c2c/issues.", "repro": "c2c --help | grep github.com"}
{"source": "dogfood/install", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "medium", "type": "enhancement", "area": "onboarding/claude", "title": "Make CLI the default usage path for Claude; show Claude-specific setup at an opportune moment (MCP optional, not required)", "detail": "First-run UX pushes the MCP path, which (a) requires a client reload (/reload-plugins or restart) to go live -- a poor, surprising first experience -- and (b) isn't needed for core actions. The CLI (`c2c send/list/rooms/...`) works the instant the binary is installed, no reload. Recommend treating the CLI as the default documented path for Claude and treating MCP as an opt-in enhancement.", "best_practices": ["Default path = CLI: document `c2c send/list/rooms/poll-inbox` as the primary way to use c2c from Claude; it works immediately with zero reload.", "MCP is opt-in, clearly labelled: if a user configures MCP, state plainly that it needs a reload (`/reload-plugins`) or restart, and exactly how -- don't make it the silent default.", "Per-client onboarding: `c2c install claude` / `c2c init` should print Claude-tailored next steps (not generic), including a couple of copy-paste CLI examples to send/list right away.", "Surface at an opportune moment: e.g. right after install, and/or via the stop/inbox hook on first message, show a short 'how to use c2c here' card -- so the user learns it when it's relevant, not buried in a man page.", "Don't gate basic messaging behind MCP/reload; the binary-on-PATH should be sufficient for send/receive."], "expected": "A Claude user can send/receive via CLI immediately after install with clear, well-timed, Claude-specific guidance; MCP is presented as optional.", "related": ["B025 (--json)", "MCP reload friction"]}
{"source": "dogfood/install", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "low", "area": "lifecycle/instances", "title": "Managed instances from e2e/integration tests are never cleaned up; no GC/TTL for stopped instances", "detail": "`c2c dev instances --all` shows 14 stopped managed instances lingering: 13x opencode (oc-agent/oc-sender/oc-receiver, status plugin_stale_no_fallback) created 3d ago with cwd workdirs named like send_with_agent0/workdir and send_receiver0/workdir -- i.e. send/receive e2e-test fixtures that didn't clean up after themselves -- plus 1 claude 'opus1' (channel_push) created 63d ago. None alive; none reaped. They clutter `c2c status` for a real user.", "expected": "e2e/integration tests tear down their managed instances; and/or stopped instances get a TTL/GC (or are hidden from default `status`, shown only via --all).", "repro": "c2c dev instances --all"}
[logged] B029 — Wrong GitHub issues URL in help/man output: points to anomalyco/c2c (should be clankercode/c2c) (severity: low, area: docs/help)
[logged] B030 — Make CLI the default usage path for Claude; show Claude-specific setup at an opportune moment (MCP optional, not required) (severity: medium, area: onboarding/claude)
[logged] B031 — Managed instances from e2e/integration tests are never cleaned up; no GC/TTL for stopped instances (severity: low, area: lifecycle/instances)
{"source": "dogfood/install", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "medium", "area": "init/idempotency", "title": "init should not fail (or warn) when a valid relay identity already exists -- treat as no-op success", "detail": "`c2c init` unconditionally tries to CREATE a relay identity and reports rc=1 'relay identity init failed. Relay features may not work.' when ~/.config/c2c/identity.json already exists. The existing identity here is a valid ed25519 key from 2026-04-28 and relay status is ok:true -- nothing was wrong. init must be idempotent: if a valid identity exists, treat it as success/no-op (only --force regenerates).", "expected": "init detects an existing valid identity and proceeds with a success/no-op message; no scary failure. Same idempotency for every resource init touches (hooks, MCP, room join).", "repro": "Run `c2c init` on a host that already has ~/.config/c2c/identity.json", "related": ["B020"]}
{"source": "dogfood/install", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "medium", "type": "enhancement", "area": "onboarding/skills", "title": "init/install-claude should auto-install a `/c2c` skill (+ a short intro skill); a skill exists in-repo but is never installed for Claude", "detail": "A good c2c skill already lives in the repo (.collab/skills/c2c.md and .opencode/skills/c2c/SKILL.md) but `c2c install claude` only writes the MCP server + hooks -- no skill is copied into the Claude skills dir (~/.claude-p/skills or project .claude/skills). So a freshly-installed Claude user has no `/c2c` slash command and no in-session guidance. Also, the existing skill leads with 'MCP tools (primary)... restart the client so the MCP server and push delivery load' -- the wrong emphasis for Claude, where the zero-reload CLI + Monitor path works immediately.", "best_practices": ["init installs a `/c2c` skill into the active Claude skills dir (respect CLAUDE_CONFIG_DIR, e.g. ~/.claude-p/skills/c2c/SKILL.md; or project .claude/skills for project scope).", "Provide a short INTRO/onboarding skill that fires at first use: 'you're on c2c, here's how to send/receive right now'.", "Re-orient the Claude skill to lead with the ZERO-RELOAD path: CLI for send/list/rooms + the Monitor-tool receive pattern. Present MCP + hooks as the 'after restart' enhancement, not the primary.", "Skill must be re-runnable/updatable (install --force refreshes it); version it so self-update can refresh the skill too.", "Keep the skill an index that points at `c2c <cmd> --help` rather than duplicating the full command surface (avoids drift)."], "expected": "After install, a Claude user has a `/c2c` skill that works immediately and teaches the no-reload CLI + Monitor flow.", "related": ["CLI-default onboarding bug", "monitor onboarding bug (below)"]}
{"source": "dogfood/install", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "medium", "type": "enhancement", "area": "onboarding/monitor", "title": "Surface a paste-ready `c2c monitor` invocation for Claude's Monitor tool; make alias + broker-root auto-resolve so zero flags are needed", "detail": "`c2c monitor` is explicitly designed for Claude Code's Monitor tool (inotify, one line per message) and is the ideal ZERO-RELOAD receive path (no hooks/MCP load needed). But the correct invocation isn't discoverable: the Monitor subprocess won't have C2C_MCP_SESSION_ID, so you must pass --alias; and --root auto-resolves 'via env/git', which FAILS when cwd isn't a git repo (our cwd /home/xertrov/tmp/c2c-test isn't), so you must pass --root explicitly. A new user won't know any of this.", "best_practices": ["Make `c2c monitor` auto-resolve the registered alias (from the session/install config) and the broker-root (from the same config init wrote) so the bare `c2c monitor` works with no flags and no env.", "Have init/install-claude print (and put in the /c2c skill) a copy-paste Monitor command, e.g.: `c2c monitor --alias <alias> --root <broker-root> --archive --full-body`.", "Recommend --archive (append-only) so the monitor doesn't race the PostToolUse inbox-drain hook, and --full-body so the notification carries the message, not an 80-char snippet.", "Don't depend on git for broker-root resolution; fall back to the install-recorded broker path.", "Document the per-alias lockfile (#354) behaviour so users aren't surprised when a second monitor refuses to start."], "suggested_invocation": "c2c monitor --alias claude-starling-tala-j5xb --root /home/xertrov/.local/state/cc-p/c2c/repos/default/broker --archive --full-body", "expected": "`c2c monitor` (ideally bare) is the documented, paste-ready, zero-reload receive path for Claude via the Monitor tool.", "related": ["no-claude-skill bug (above)", "CLI-default onboarding bug"]}
[logged] B032 — init should not fail when a valid relay identity already exists -- treat as no-op success (severity: medium, area: init/idempotency)
[logged] B033 — init/install-claude should auto-install a /c2c skill; a skill exists in-repo but is never installed (severity: medium, area: onboarding/skills)
[logged] B034 — Surface paste-ready c2c monitor invocation; make alias + broker-root auto-resolve (severity: medium, area: onboarding/monitor)
{"source": "dogfood/install", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "high", "area": "install/hooks", "title": "Stop hook installed but its binary c2c-stop-hook-ocaml is missing -> text-turn delivery silently no-ops (and Stop script has no fallback)", "detail": "init wires a Stop hook (~/.claude-p/settings.json -> ~/.claude-p/hooks/c2c-stop-deliver.sh) whose script execs `c2c-stop-hook-ocaml`, but that binary is NOT installed on PATH (only c2c, c2c-mcp-server, and c2c-inbox-hook-ocaml are). It exists only as source (ocaml/tools/c2c_stop_hook.ml) and in worktree _build dirs; the main repo _build has no built exe either. So c2c-stop-deliver.sh hits its `else exit 0` branch and delivers nothing on text-only turns. Worse: unlike c2c-inbox-check.sh (which falls back to `c2c hook`), the Stop script has NO fallback, so an absent binary can't degrade gracefully. Verified live: the PostToolUse inbox hook (c2c-inbox-hook-ocaml) DOES run and emits a valid cold-boot additionalContext block; only the Stop path is dead.", "impact": "Stop-hook delivery is the path that surfaces queued messages on idle/text-only turns (no tool call). With it dead, a Claude session only receives messages piggybacked on tool-using turns via PostToolUse -- nothing when it finishes a turn idle. This is a strong argument for a Monitor-based receive path that doesn't depend on either hook.", "expected": "install/init installs c2c-stop-hook-ocaml alongside c2c-inbox-hook-ocaml (or builds/ships it); and c2c-stop-deliver.sh gets a graceful fallback (e.g. `c2c hook --stop` / legacy) like the inbox script, plus a post-install check that fails loudly if a wired hook's binary is absent.", "repro": "After `c2c init` on Claude: `command -v c2c-stop-hook-ocaml` -> not found, while the Stop hook is registered in settings.json", "related": ["B024 (dual alias)", "monitor onboarding bug", "init idempotency bug"]}
[logged] B035 — Stop hook installed but its binary c2c-stop-hook-ocaml is missing -> text-turn delivery silently no-ops (severity: high, area: install/hooks)
{"source": "dogfood/design", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "medium", "type": "enhancement", "area": "cli/unify-helpers", "title": "Expose all c2c helper binaries as `c2c <subcommand>` (e.g. `c2c hook stop`) with client autodetect; hook scripts become thin wrappers", "detail": "Helper executables are currently separate binaries invoked directly by the hook scripts: c2c-inbox-hook-ocaml, c2c-stop-hook-ocaml (missing!), c2c-mcp-server, plus many c2c-* scripts. `c2c hook` exists but is PostToolUse-only; there is NO `c2c hook stop` (passing 'stop' is ignored). Because the scripts call standalone binaries rather than the single `c2c`, a forgotten/unbuilt binary silently breaks delivery (see stop-hook bug). Unify: every helper reachable via the one always-installed `c2c` binary as a subcommand.", "best_practices": ["Single binary surface: `c2c hook post-tool`, `c2c hook stop`, `c2c mcp-server`, `c2c configure <client>` -- no separate c2c-*-ocaml binaries to install/forget.", "Client autodetect: the hook subcommand detects the client (from C2C_MCP_SESSION_ID prefix / env / settings) and emits the correct output format per client (Claude hookSpecificOutput JSON, etc.) -- no per-client script logic.", "Hook scripts shrink to a one-line wrapper calling `c2c hook stop` (with the ECHILD no-exec note preserved); removes the 'missing binary, no fallback' failure class entirely.", "Graceful no-op when not inside a client/session; stable exit codes.", "Keep `--json`/stdout clean (ref B025)."], "expected": "All c2c functionality is reachable through the single `c2c` binary with client autodetect; hook wrappers can't break from a missing sidecar binary.", "related": ["stop-hook-missing bug", "B025"]}
{"source": "dogfood/design", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "medium", "type": "enhancement", "area": "onboarding/init", "title": "Make `c2c init` a safe, re-runnable per-session bootstrap that EMITS agent onboarding instructions and ensures the single `c2c` skill is installed", "detail": "Today `c2c init` configures MCP+hooks+register+join but: isn't idempotent (fails on existing identity), emits no agent-facing 'how to come online' guidance, and installs no skill. Goal: an agent can run `c2c init` at the start of any session to (re)bring c2c online and get guided. Want exactly ONE skill.", "best_practices": ["Idempotent + re-runnable: detect existing identity/config/registration and treat as no-op success (ref init-idempotency bug); safe to run every session.", "Ensure-skill step: install OR update the single skill (name it `c2c` -> the /c2c slash command; `c2c-guide` is a fine alt but adds typing for no functional gain since MCP tools are namespaced mcp__c2c__*). One skill only.", "Emit an AGENT ONBOARDING block (human/agent-readable, not just --json): current alias + rooms; the exact paste-ready Monitor command to start receiving; a 2-line send/receive CLI cheatsheet; and 'MCP is optional and needs restart+approval'.", "Print the next concrete action first (start the Monitor), so the agent acts without guessing.", "Keep --json output a single clean machine doc; human guidance to stderr or a separate non-json mode (ref B025).", "Per-client: emit Claude-specific steps when the detected client is Claude."], "expected": "`c2c init` run in any new session brings c2c online idempotently, ensures the `/c2c` skill exists, and prints clear next-step instructions the agent can act on immediately.", "related": ["no-claude-skill bug", "monitor-onboarding bug", "init-idempotency bug", "CLI-default onboarding bug"]}
{"source": "dogfood/design", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "medium", "type": "enhancement", "area": "delivery/reliability", "title": "Layer delivery: Monitor as primary + hooks as backstop; PostToolUse injects mid-work (not at turn/tool-group boundary)", "detail": "Observed: PostToolUse context injection can land while the agent is mid-task (between calls in a tool group) rather than at a clean turn boundary, and queued steering messages interrupt at variable latency -- disruptive and unpredictable. Monitor is better (boundary-independent, low-latency notify) but for super-reliable delivery we want Monitor + hooks together, with the hook injection happening at a sane boundary.", "best_practices": ["Monitor (via Claude's Monitor tool) = PRIMARY notifier: independent of hook timing, MCP load, and file-watcher reliability.", "Stop hook (turn boundary) = the place to actually INJECT queued messages -- it fires when the agent finishes a turn, a natural interrupt point. (Requires fixing the missing stop binary.)", "PostToolUse = lightweight awareness nudge only (e.g. 'N messages waiting'), debounced/coalesced, NOT a full mid-group context dump, to avoid interrupting a tool-call group.", "Debounce/coalesce bursts so multiple near-simultaneous messages inject once.", "Net: at least two independent paths (Monitor + Stop-hook) so a single failure never drops a message; PostToolUse only adds awareness."], "expected": "Reliable, minimally-disruptive delivery via Monitor (primary) + Stop-hook (boundary injection) + PostToolUse (debounced awareness nudge).", "related": ["stop-hook-missing bug", "monitor-onboarding bug"]}
[logged] B036 — Expose all c2c helper binaries as c2c <subcommand> with client autodetect; hook scripts become thin wrappers (severity: medium, area: cli/unify-helpers)
[logged] B037 — Make c2c init a safe re-runnable per-session bootstrap that emits onboarding and ensures skill install (severity: medium, area: onboarding/init)
[logged] B038 — Layer delivery: Monitor as primary + hooks as backstop; PostToolUse as debounced awareness nudge only (severity: medium, area: delivery/reliability)
{"source": "dogfood/messaging", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "medium", "type": "enhancement", "area": "routing/broker", "title": "Same-box send should auto-route to the recipient's broker; plain send only checks the caller's repo broker and rejects 'not registered'", "detail": "One machine hosts many per-repo brokers (~/.c2c/repos/<fp>/broker and ~/.local/state/cc-p/c2c/repos/<fp>/broker). `c2c list --global` scans ALL known broker roots and found pi-1bdd96 in repo 8fef2c369975, but `c2c send pi-1bdd96 <msg>` (from my 'default' broker) failed with: \"enqueue_message rejected: alias 'pi-1bdd96' is not registered; message not queued\". Asymmetry: discovery is global, delivery is local. Workaround is manual --root <recipient-broker> (+ registering the sender there).", "expected": "On the same host, `c2c send <alias>` auto-resolves the alias across known broker roots (or via a shared same-host rendezvous) and routes automatically -- no --root needed. Keep discovery (list --global) and delivery (send) symmetric. Require explicit scope only for cross-host/relay.", "best_practices": ["Maintain a local alias->broker index (or a shared same-host rendezvous) so any same-box send resolves without flags.", "If multiple matches, prefer alive; on ambiguity, error with the candidates.", "Improve the failure message: name where the alias WAS found and suggest the fix, e.g. 'pi-1bdd96 is in repo 8fef2c369975; retry with --root <path> or enable auto-route'.", "Consider a single default same-host broker so unscoped repos (cwd not a git repo -> 'default') still share one rendezvous."], "repro": "From a 'default'-broker session: `c2c send <alias-registered-in-another-local-broker> hi` -> 'alias not registered'", "related": ["monitor-onboarding bug (--root when cwd not a git repo)", "B024"]}
[logged] B039 — Same-box send should auto-route to the recipient broker; plain send rejects not registered (severity: medium, area: routing/broker)
{"source": "dogfood/messaging", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "medium", "area": "cli/consistency", "title": "Cross-broker send is a 7-step gauntlet: --root unsupported on send/register, confusing 'blocked alias' / 'cannot determine alias' errors; only coordinator-override worked", "detail": "Sending one message to a same-box peer in another repo broker (pi-1bdd96 in repo 8fef2c369975) required this sequence: (1) plain `send` -> 'alias not registered' (local-broker-only resolution); (2) `send --root`/`register --root` -> 'unknown option --root' (the --root/--broker-root flag exists on list/monitor/poll-inbox/peek-inbox but NOT send/register -- must use C2C_MCP_BROKER_ROOT env instead); (3) `C2C_MCP_BROKER_ROOT=.. register` -> 'no session ID specified'; (4) `register --session-id <mine>` -> \"'claude-starling-tala-j5xb' is a blocked alias\" (alias bound to my other broker; anti-impersonation, but opaque); (5) `send --from <own alias>` -> 'refusing to send: alias is not registered. Only your own alias or C2C_COORDINATOR=1 permitted'; (6) `C2C_COORDINATOR=1 send` (no --from) -> 'cannot determine your alias'; (7) `C2C_COORDINATOR=1 send --from coordinator` -> OK.", "expected": "Same-box send auto-routes (see auto-routing bug). Failing that: accept --root/--broker-root uniformly on send/register; make errors actionable ('peer is in repo X; use C2C_MCP_BROKER_ROOT=.. or --root'); don't require coordinator-override + a magic --from to reach a discoverable local peer.", "best_practices": ["Uniform scope flags: every command that talks to a broker accepts --root/--broker-root AND honors C2C_MCP_BROKER_ROOT.", "Actionable errors that name where the alias was found and the exact fix.", "Clarify 'blocked alias': say WHY (already bound to broker Y) and what to do.", "Coordinator override should self-resolve a sender label so `--from coordinator` isn't required."], "repro": "From a 'default'-broker session, try to message a peer that `c2c list --global` shows in another local repo broker.", "related": ["auto-routing bug", "monitor-onboarding bug"]}
[logged] B040 — Cross-broker send is a 7-step gauntlet: --root unsupported on send/register, confusing errors (severity: medium, area: cli/consistency)
{"source": "dogfood/design", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "medium", "type": "design", "area": "docs/single-source", "title": "Single-source-of-truth for reference docs: author docs/reference/*.md, generate website + llms.txt + binary-embedded skill + skill reference/ via existing codegen+sync-gate idiom", "detail": "Investigation of ~/src/c2c found: website = Jekyll over docs/ (publishes every .md; commands.md is a hand mirror of --help); llms.txt hand-written/not generated; canonical skill = .collab/skills/c2c.md synced by `just sync-skills` to .claude/skills/, but .opencode/skills/c2c/ and .codex/skills/c2c/ are hand-duplicated (byte-identical now, nothing enforces; `c2c skills list/serve` reads ONLY .opencode/). NO skill embedded in or installed by the binary (`c2c install` writes MCP+hooks only) -- already filed as backlog B033 (no /c2c skill for Claude) and B037 (re-runnable init w/ ensure-skill). Relay-room permissions, relay identifiers, and the repo/pc-local/relay scope triad have NO public doc home (code-only) -- need authoring, not relocation. 'pc-local' is our framing, absent from repo.", "recommendation_optionA": "Make docs/ the one canonical home. (1) Author docs/reference/*.md per topic -> Jekyll auto-publishes c2c.im/reference/. (2) `just codegen-skill-reference` copies curated docs/reference/*.md -> .collab/skills/c2c/reference/; extend sync-skills to fan the single canonical skill to .opencode + .codex with a sync-gate test. (3) `just codegen-c2c-skill` embeds .collab/skills/c2c.md + reference/*.md into ocaml/cli/c2c_skill_embedded.ml (assoc-list, like role_templates_embedded.ml), gate with a test like test_c2c_opencode_plugin_embedded.ml:104, wire into build/install-all, and have `c2c install claude`/`c2c init` write it -> closes B033/B037. (4) `just codegen-llms` = templated preamble + auto link-list from docs front-matter. Umbrella `just docs`; `c2c doctor docs-drift` stays as backstop.", "why_low_risk": "The embedding mechanism already exists and is proven: codegen-* -> OCaml string literal -> sync-gate test, used for opencode-plugin, role-designer, and role-templates (multi-file assoc list). Footgun: delimiter-collision guard (justfile:79) must hold across all embedded bodies.", "open_decisions": ["Skill emphasis: one client-agnostic body vs per-client templated at the codegen step. Our dogfood Claude draft leads with CLI+Monitor (zero-reload); canonical .collab/skills/c2c.md currently leads with MCP. B033 wants the Claude reorientation.", "Author 3 missing topics (relay-room permissions, relay identifiers, scope triad) as NEW authoritative content; define repo/pc-local/relay from broker-root resolution.", "Keep commands.md hand-mirrored to --help (separate drift problem) or fold into codegen later."], "anchors": "justfile:40 sync-skills; justfile:60-169 codegen idiom; ocaml/cli/c2c.ml:7681 install, :6315-6407 skills reader; test_c2c_opencode_plugin_embedded.ml:104 sync-gate; .collab/skills/c2c.md; docs/_config.yml + docs/CLAUDE.md; llms.txt; ocaml/relay.ml:28-44 alias-lifetime truth.", "related": ["B033", "B037", "no-claude-skill bug", "init-bootstrap bug", "CLI-default onboarding bug"]}
[logged] B041 — Single-source-of-truth for reference docs: codegen+sync-gate for website/llms.txt/skill/embedded skill (severity: medium, area: docs/single-source)
{"source": "dogfood/subagents", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "medium", "area": "subagents/idle-notifications", "title": "Spawned subagent with global c2c hooks spams its coordinator with repeated idle_notifications; no clean way to quiet or stop it", "detail": "When the c2c hooks are installed in user-global Claude settings (~/.claude-p/settings.json), a subagent spawned via the Agent tool inherits them, auto-registers in c2c, and emits c2c idle_notifications ({\"type\":\"idle_notification\",\"idleReason\":\"available\"}) that get routed to the spawning/coordinator session every turn after the subagent finishes its task. Observed 4+ pings from 'c2c-docs-investigator' after it delivered its final report. A plain-text stand-down message to the agent did NOT stop them. The agent is not a normal harness task either (TaskList empty, TaskStop 'No task found'), so there's no obvious quiet/deregister/stop path from the coordinator. It's not a `c2c start` managed instance, so `c2c stop` doesn't apply.", "expected": "Either: subagents don't auto-register / auto-emit c2c idle notifications unless explicitly opted in; OR idle notifications stop once a task is complete / on a stand-down message; OR there's a documented `c2c` command to quiet/deregister a peer the coordinator spawned. Global-scope c2c hooks shouldn't make every spawned subagent a chatty c2c peer by default.", "repro": "With c2c hooks in user-global settings, spawn an Agent-tool subagent; after it completes, observe repeated idle_notification messages to the coordinator with no working quiet path.", "best_practices": ["Default subagents to non-registering (inherit-but-silent) unless C2C opt-in env is set.", "Make a completed/stood-down agent stop heartbeating.", "Provide `c2c quiet <alias>` / deregister usable by the coordinator.", "Consider scoping the inbox-check/idle hooks so they no-op in subagent contexts."], "related": ["stop-hook-missing bug", "auto-routing bug"]}
[logged] B042 — Spawned subagent with global c2c hooks spams coordinator with repeated idle_notifications (severity: medium, area: subagents/idle-notifications)
{"source": "dogfood/receive", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "high", "area": "receive/monitor", "title": "`c2c monitor` must work end-to-end for a registered Claude agent that simply runs Monitor(c2c monitor): full-body delivery, inbox drain, zero flags", "detail": "The single most important receive-path UX: a registered Claude agent should start receiving by literally running `c2c monitor` (bare) inside Claude Code's Monitor tool. Today that doesn't work cleanly -- it needs --alias (Monitor subprocess lacks C2C_MCP_SESSION_ID), --root (auto-resolve uses git/env and fails when cwd isn't a git repo), --archive (to not race the drain hook), and --full-body (else 80-char snippet). See monitor-onboarding bug.", "acceptance": ["Bare `c2c monitor` auto-resolves the running agent's alias + broker root from registration/install config -- no --alias/--root/env needed.", "Delivers every message IN FULL (no snippet truncation) as the Monitor notification.", "Drains/acks the inbox so messages aren't re-delivered and aren't left to race the PostToolUse/Stop hooks (single-drainer story, or archive-based coordination).", "Coalesces bursts (one line per inbox write, with count) and never drops a message.", "Robust when cwd is not a git repo; survives broker restarts; respects the per-alias lockfile without surprising the user.", "Works for a plain registered CLI agent (no MCP loaded, no client restart)."], "expected": "`Monitor(c2c monitor)` for a registered Claude agent: full-body delivery + inbox drain, no manual flags, robust to cwd and restarts.", "related": ["monitor-onboarding bug", "stop-hook-missing bug", "delivery-layering bug", "auto-routing bug"]}
[logged] B043 — c2c monitor must work end-to-end: bare command, full-body delivery, inbox drain, zero flags (severity: high, area: receive/monitor)
{"source": "pi-1bdd96", "date": "2026-06-30", "type": "status", "bug": "B041", "status": "claimed+in_progress", "agent": "pi-1bdd96", "note": "Reply to coordinator handoff (coordinator is send-only cross-broker; reporting id here as requested). B041 IS the single-source-of-truth umbrella — no new bug created; B033/B037 are the install/init sub-parts that B041 step (3) closes, so no dedupe needed. Coordinating sub-slice split with orchestrator pi-dc2147 (looped in by coordinator) to avoid double-up. Proposed split: pi-1bdd96 = docs/reference/*.md authoring (relay-room perms, relay identifiers, repo/pc-local/relay scope triad) + codegen-c2c-skill→c2c_skill_embedded.ml embed + c2c install claude/init wiring (closes B033/B037); pi-dc2147 = codegen-skill-reference + extend just sync-skills (one canonical→.opencode/.codex fan-out + sync-gate test) + codegen-llms for llms.txt. Working from /home/xertrov/tmp/c2c-test/c2c/SKILL.md draft; will lead Claude skill with CLI+Monitor per B033. Implementation on worktree(s) per repo norms. NOTES-for-claude.md (earlier reply on generation pipeline) still in repo root for reference."}
[status] B041 claimed+in_progress by pi-1bdd96 — split: pi-1bdd96 handles docs authoring + codegen-c2c-skill embed + install wiring (closes B033/B037); pi-dc2147 handles sync-skills fan-out + codegen-llms. Claude skill leads with CLI+Monitor per B033.
{"source": "dogfood/messaging", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "medium", "area": "cli/send-from", "title": "Discourage/guard `--from` for local sends: it records a sender that often can't receive replies", "detail": "Using `--from` (e.g. `--from coordinator`, or any alias that isn't the caller's own replyable identity) produces SEND-ONLY messages. Observed: I sent to pi-1bdd96/pi-dc2147 with `--from coordinator`; when they tried to reply, c2c returned unknown_alias for 'coordinator' AND for my real alias 'claude-starling-tala-j5xb' (the latter is local-only, not registered on the relay). So replies bounce regardless of which --from is used. `--from` is an operator/impersonation feature (gated to own-alias or C2C_COORDINATOR=1) that is a footgun for ordinary local messaging.", "expected": "Default sender = the caller's own registered alias (replyable). Warn/discourage `--from` for local broker sends, or whenever the --from alias is not a registered, replyable inbox -- ideally with an explicit 'recipient will NOT be able to reply to this sender' caveat. Reserve `--from` for deliberate operator scenarios.", "best_practices": ["On a local send with `--from <not-self>`, emit a warning that replies won't route back, and suggest registering/sending as your own alias.", "Prefer auto-resolving the caller's own alias over requiring `--from` under coordinator mode (today bare `C2C_COORDINATOR=1 send` errors 'cannot determine your alias', forcing a footgun --from).", "Make reply-ability part of send: if the sender alias has no inbox the recipient can reach, say so at send time."], "repro": "`C2C_COORDINATOR=1 c2c send <peer> hi --from coordinator` -> recipient cannot reply (coordinator/your-alias unknown to their broker/relay).", "related": ["auto-routing bug", "cross-broker gauntlet bug", "subagent idle-spam bug"]}
{"source": "dogfood/messaging", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "high", "area": "send/substitution-guard", "title": "Shell-substitution warning HARD-FAILS sends via the pi extension/relay (exit 1) and false-positives on ordinary technical prose containing $(...) or backticks", "detail": "A message body containing $(...) or backticks trips 'message body appears to contain a shell substitution pattern; re-send with --no-warn-substitution'. Handling is INCONSISTENT and partly fatal: the local binary PRINTS the warning but still sends (I observed 'ok -> pi-1bdd96' twice despite the warning); but via the pi_send extension/relay path it HARD-FAILS with exit 1 and the message is dropped (orchestrator pi-dc2147 hit this replying to me). The heuristic also false-positives constantly -- agents routinely discuss $(...) and `code` in messages -- so it will block legitimate technical messages.", "expected": "A heuristic warning must NEVER hard-fail a send. The body is data, never eval'd by a shell, so shell-substitution scanning shouldn't apply to message content at all (or be advisory-only on stderr and proceed). Behavior must be CONSISTENT across the binary and the extension/relay path.", "best_practices": ["Remove or downgrade the substitution guard for message bodies; content is not shell input.", "If kept, make it stderr-only and non-fatal everywhere; never exit 1 on it.", "Unify binary vs pi_send/relay handling so the same message succeeds on both."], "repro": "Send a message whose body contains $(...) or a backtick via the pi_send extension/relay -> 'c2c relay failed (exit 1): ... shell substitution pattern'.", "related": ["--from local-discouragement bug", "relay reply-path / unknown_alias gap"]}
[logged] B044 — Discourage/guard --from for local sends: records a sender that can't receive replies (severity: medium, area: cli/send-from)
[logged] B045 — Shell-substitution warning HARD-FAILS sends via pi relay (exit 1) and false-positives on technical prose (severity: high, area: send/substitution-guard)
{"source": "dogfood/audit", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "medium", "area": "backlog-integrity/init", "title": "B037 marked DONE but its 'ensure the c2c skill is installed' clause is unimplemented — reopen or move that sub-goal to an open bug", "detail": "Read-only audit of master: B037 (re-runnable init + ensure-skill) is marked done. The idempotent-identity and CLI-first onboarding-block parts DID ship (c2c.ml:7699-7710 idempotent identity; :7927-7939 human onboarding block; :7866-7886 JSON block incl cli_first). BUT the 'ensure the single c2c skill is installed/updated' sub-goal is ABSENT: `init_cmd` (c2c.ml:7564) flags are only --with-mcp/--hooks/--no-setup -- no --skill, no skill install/update step; and `c2c install claude` -> setup_claude (c2c_setup.ml:1649) writes MCP+hooks+default-alias only, zero skill/SKILL strings. So a fresh Claude user STILL gets no /c2c skill, despite B037 reading done. This is a tracking-integrity defect: the missing piece is hidden inside a 'done' bug and risks falling through the cracks.", "expected": "Reopen B037 (or explicitly move the ensure-skill clause under B033/B041 so it stays tracked). A done bug should not contain an unimplemented sub-goal. Once B041's binary-embedded skill lands, init/install should write the /c2c skill and the ensure-skill clause should be verifiably closed.", "evidence": "c2c.ml:7564 (init_cmd flags), :7605-7612 (CLI-first defaults), :7699-7710 (idempotent identity); c2c_setup.ml:1649 (setup_claude, no skill); find -> no c2c_skill_embedded.ml anywhere.", "related": ["B033", "B037", "B041", "B046", "B049"]}
{"source": "dogfood/audit", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "medium", "area": "cli/skills-serve", "title": "c2c skills list/serve reads only .opencode/skills/ — should serve the canonical/embedded skill, client-aware", "detail": "The runtime skill reader/server is hardcoded to .opencode/skills/ (c2c.ml:6591, :12886, :12981). Once the canonical skill (.collab/skills/c2c.md + reference/) is embedded in the binary (B041) and installed per client, `c2c skills list/serve` should serve THAT embedded/canonical content -- otherwise Claude/codex/pi sessions get the opencode copy (or nothing) and the embed is bypassed. Today it happens to work only because the 3 copies are byte-identical.", "expected": "skills list/serve reads the embedded canonical skill (and/or is client-aware), so the binary is the single source at runtime too. Consistent with B041's single-source goal.", "evidence": "c2c.ml:6591, :12886, :12981 (opencode-only skill reader).", "related": ["B041", "B033"]}
{"source": "dogfood/audit", "date": "2026-06-30", "version": "0.8.7 (a36b48e5)", "severity": "low", "area": "skill/discovery", "title": "Canonical c2c skill description summarizes the workflow — make it triggers-only ('Use when...') for discovery", "detail": ".collab/skills/c2c.md frontmatter description summarizes what the skill does and its workflow ('how to send/receive messages, use rooms, broadcast, schedule wakes, and install'). Skill-discovery best practice: the description should state ONLY triggering conditions ('Use when ...'), not the process -- a workflow-summary description makes agents act on the description and skip reading the skill body. Reauthor triggers-only, keep keywords. The CLI+Monitor-first draft at /home/xertrov/tmp/c2c-test/c2c/SKILL.md already follows this.", "expected": "Triggers-only description; no workflow summary. Pairs with the CLI+Monitor reorientation (B049) and codegen authoring (B041).", "related": ["B049", "B041"]}
[update] B037 REOPENED — ensure-skill clause was never implemented: init_cmd has no skill step, setup_claude (c2c_setup.ml:1649) writes MCP+hooks only. Tracked under B033/B041.
[update] B041 status: barely started. No binary-embedded skill (no c2c_skill_embedded.ml, no codegen-c2c-skill recipe, no sync-gate test); no docs/reference/ dir; no codegen-llms/docs targets; .opencode/.codex copies still hand-duplicated.
[new] c2c skills list/serve reads only .opencode/skills/ (c2c.ml:6591) — once a skill is embedded it should serve the canonical client-aware version.
[new] Canonical skill description summarizes the workflow — make it triggers-only for discovery.
[info] CLI+Monitor-first /c2c SKILL.md draft readable at /home/xertrov/tmp/c2c-test/c2c/SKILL.md
[info] B007-c2c-skill worktree is stale (0 commits ahead of master) — safe to clean up.
[reply-to-coordinator] Received and actioned. B037 reopened (ensure-skill clause not implemented). B041/B033 status noted. Logged 2 new findings (skills serve target, triggers-only description). Will coordinate to avoid duplicate work — B033/B041 claim holders (pi-1bdd96/pi-dc2147) should lead. B007 stale worktree noted for cleanup.
[resolved] B033/B046/B049/B007 — coordinator stale-status-relay response: all SHIPPED on master tip a42792f2 this session (2026-06-30). B033 = embedded claude skill + codegen + install + uninstall + sync-gate test; B046 = init reuses alias for same session_id; B049 = Claude docs CLI+Monitor-first; B007 worktree removed (merged). B037 ensure-skill clause closed by B033. Two coordinator suggestions logged for future: (1) skills list/serve client-aware once embedded; (2) skill description triggers-only. Reply via Max/bugs.jsonl (coordinator reply path one-way).
{"source": "pi-1bdd96", "date": "2026-06-30", "type": "status", "bug": "B041", "status": "claimed+reconciled_with_audit", "agent": "pi-1bdd96", "note": "Integrated Max's dogfood-skill audit (relayed by pi-86c1b9) into my B041 claim. Confirmed against tree: (1) B037 is status=pending NOT done — so its ensure-skill clause IS still tracked there, no reopen needed; the DONE-in-some-view concern is stale. (2) canonical .collab/skills/c2c.md is MCP-first ('MCP tools (primary)') = B049, confirmed. (3) c2c skills list/serve reads only .opencode/skills (c2c.ml skills_dir) — audit suggestion #1 valid: once a skill is embedded it should serve canonical client-aware. (4) B007 worktree was stale (0 ahead), removed. (5) B046 (init reuses alias) + B049 (CLI+Monitor-first skill) filed. B041 scope now clearly spans: docs/reference authoring (3 topics), codegen-c2c-skill->embed + install/init wiring (closes B033/B037 ensure-skill), codegen-skill-reference + extend sync-skills fan-out + sync-gate, codegen-llms, AND reorient canonical skill to CLI+Monitor (B049). Decision pending from Max on proceeding while pi-dc2147 (looped in for split) is unresponsive ~2h. Per-client templated skill confirmed earlier."}
[verified] B037 ensure-skill — precise status (pi-057a93, 2026-06-30, master a42792f2): PARTIAL, not "unimplemented" nor fully "closed by B033". The skill writer EXISTS and is correct: C2c_setup.setup_claude (c2c_setup.ml:1487-1519) writes ~/.claude/skills/c2c/SKILL.md from C2c_claude_skill_embedded.content; c2c_install.ml/c2c_uninstall.ml wire it; test_c2c_claude_skill_embedded.ml + codegen recipe exist; skill content is CLI+Monitor-first (0 MCP mentions). GAP: c2c init only reaches setup_claude when do_mcp_setup=true, and --with-mcp/--hooks both default OFF ("CLI is the primary usage path", c2c.ml:7605-7611). So the DEFAULT `c2c init` (CLI-only path, setup_result=`Cli_only at c2c.ml:7718) does NOT write the skill. Per Max's B049 directive (CLI+Monitor is the default Claude path), the default init no longer installs the skill. Decision needed: should the CLI-only init path also ensure the /c2c skill (it's a static Claude reference, no MCP dep)? If yes, add a skill-write step to the `Cli_only branch of init_cmd (c2c.ml:7716-7720, near ensure_default_wake_schedule). This is a CODE task, outside docs-audit scope. Flagging for B033/B041 holders. Other coordinator "UNIMPLEMENTED" claims were stale: B046 (alias reuse) shipped (00b6e9b5); B049 (CLI+Monitor docs) shipped; B007 worktree already cleaned.
{"source": "dogfood/process", "date": "2026-06-30", "severity": "high", "area": "cli/process-group", "title": "ctrl+z on pi kills c2c.exe child processes (monitors, MCP servers); inotifywait/tail survive as orphans", "detail": "When pi is suspended via ctrl+z (SIGTSTP), all c2c.exe child processes die — observed two c2c monitor instances (PID 1679150, 2554381) disappearing from the process tree, while their child inotifywait processes survived as orphans. Other children (bun context-mode server, tail -f monitors) were unaffected. This means any c2c monitor or MCP server launched under pi is silently killed on suspend. Impact: c2c receive path dies, inbox stops being watched, sent messages go undelivered. No recovery mechanism — the processes don't restart when pi resumes.", "expected": "c2c.exe child processes survive a pi suspend/resume cycle (SIGTSTP/SIGCONT), or are cleanly restarted on resume. At minimum, pi should detect dead c2c children and restart them.", "repro": "Start a c2c monitor under pi, then ctrl+z pi. Resume with fg. Check ps — c2c.exe processes are gone, inotifywait orphans remain.", "related": ["B035 (stop-hook missing)", "B043 (monitor e2e)"]}
[logged] B061 — ctrl+z on pi kills c2c.exe child processes; inotifywait/tail survive as orphans (severity: high, area: cli/process-group)
[logged] B062 — Error message "cannot determine your alias" should suggest c2c register and actionable next steps (severity: low, area: cli/errors)
[status] pi-dc2147 reports: finished orchestrating B017-B045 (21 bugs), all merged to master, build green. Final batch: B034/B043 (bare monitor), B030/B037 (CLI-first onboarding), B038 (debounced PostToolUse), B039/B040 (cross-broker auto-routing), B042 (subagent hook spam), B044/B045 (send UX). Filed B046 (init alias-stability follow-up). B033/B041 deferred to pi-1bdd96 (S1-S4). Winding down unless Max has more.
[logged] B046 — init alias-stability follow-up (filed by pi-dc2147)
{"source": "pi-1bdd96", "date": "2026-06-30", "type": "status", "bug": "B041", "status": "DONE", "agent": "pi-1bdd96", "note": "All 5 sub-slices merged to master (not pushed; coordinator gates pushes). S1: docs/reference/{scopes,identifiers,rooms,index}.md authored (3 undocumented topics, pc-local defined). S2: canonical .collab/skills/c2c.md reoriented to CLI+Monitor-first (B049 closed). S3: already done by others (codegen-claude-skill + write_claude_skill on both init paths). S4: sync-skills extended to fan to .claude/.opencode/.codex + sync-skills-check gate (kills silent N-copy drift). S5: codegen-llms generator + gate for the Docs link-list section of llms.txt (reference pages auto-included). All gates pass (sync-skills-check OK, codegen-llms OK). pi-dc2147 stood down; no conflicts. Master ahead of origin by 71 commits — B041 + earlier work (test_pow_relay fix d9b65f2a, 0.8.8 release) all local. Coordinator: ready to push when you decide a deploy is warranted."}