sync(memory): backup auto-memory snapshot iter9 close

Mirror of ~/.claude/projects/-Users-pp-bot/memory/ as of 2026-04-27.

Files:
- MEMORY.md (index)
- dasheng-codebase.md (Gitea + IM family + 取经团 worker layout)
- feedback_bot_node_field.md (bots.json node field is informational)

Per-user Claude memory is Mac-local. This repo is the canonical backup
so a fresh machine / EC2 / colleague workstation can prime new Claude
Code windows with the same project knowledge.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
PP-bot
2026-04-27 14:38:36 +09:00
parent a11440dc1a
commit f287ba99db
3 changed files with 115 additions and 0 deletions

View File

@@ -0,0 +1,15 @@
---
name: bots.json node field is informational, not routing
description: When working with the dasheng claude-worker-universe bot registry, do not block planning or PRDs on resolving the node field for sub-bots; many run on colleague machines that the user does not own.
type: feedback
originSessionId: c2c569ed-e20b-4000-a286-8d48afea8d86
---
In `jx-im/claude-worker-universe/config/bots.json`, the `node` field on each bot entry is **informational, not behavioral**. Many sub-bots run on colleague machines outside the user's control. Do not treat unknown / unverified `node` values as blockers.
**Why:** User feedback 2026-04-25 iter2 of /ralph: "子机器人很多都是同事的机器 所以不要纠结在哪里" — many sub-bots are colleague-owned. The dispatch system uses Gitea labels + dashboard KV for routing, not the `node` field; bots self-register at startup.
**How to apply:**
- When designing or PRD-ing changes that touch bots.json, do NOT add acceptance criteria like "every bot has a verified node value" — accept `node="unknown"` or stale values.
- When asking the user about a new bot, DO NOT make the node a blocker question; default to `MacBook` (this user's primary machine) and let the colleague update it later if they own the bot.
- For 文殊菩萨 specifically: it runs on the same node as 唐僧 (MacBook) per separate instruction; that's fixed.
- Routing decisions (H5 vs iOS, qa_priority verify-first) come from `platforms` + `qa_priority` + `role_type` fields — never from `node`.